SOA & Data integrity

You may also like...

1 Response

  1. Interesting sightings Dennis. Clemens certainly has a point stating schema dependencies between services is a bad practice. For me this is an indication Clemens and many others in the field spend way to much time abstracting the SOA principles to the public instead of bringing these “revolutionary” concepts into practice. I’ve been working on a material traceability system for over a year now where we split functionality in self contained containers. We therefore have a material service storing material definitions and material instances. On the side we have an equipment service which stores equipment definitions, configurations, and instances. The material tracking service (a small part of the whole) ties the two together, the tracking services relates material check- ins/outs to equipment. In the real world this would mean I check-out material (3 parts for instance) from the warehouse, where the warehouse is actually an equipment instance. The material is then transported by a conveyer (equipment) and is being checked-in in the production center where it eventually becomes 1 part (the 3 parts being assembled together of some other process step).

    This use-case would ask the material service for the part definition, which could be an interface over some fancy ERP system. To determine if the parts are in stock it then then makes a request to the equipment service which interfaces against a piece of MES business logic, retrieving the actual stock for us. It then relates the material handling with the actual equipment being used and sends the information to a message queue (we use MSMQ for our message based integration approach). The message only contains the material and equipment ID’s which are GUID’s in our case and the “actuals”, start datetime, end datatime, amount, operator/system etc. The material tracking service achieves this information.

    If you look closely you would notices that all services are isolated self contained containers, all storing their share of data and exchanges this data upon requests. The explicit interfaces abstract the clients completely from the underlying data stores. Though the services described are definitely schema dependent. The material tracking service depends on the material / equipment schema. Although the material services is “replaceable” the equivalent should speak the same language! SOA doesn’t only force another POV towards system architecture, it also forces architects to agree upon dependencies between the explicit boundaries of your services. We therefore need flexible business standards like BatchML, B2MML where a common set of schemas is agreed upon and the standard decides which part of schema and thus data is encapsulated within a service boundary.

    And you are correct, there are no examples which explain real world scenario’s as the one briefly described above. I also think examples would confront the SOA evangelist with SOA’s shortcomings which are to busy atm with hyping SOA.

Click on a tab to select how you'd like to leave your comment

Leave a Reply

Your email address will not be published. Required fields are marked *