SOA-2(b): More on the integration layer
I had discussed the design of our integration layer in an earlier post and Stuart commented asking if we implemented the messaging layer using messaging only or if we needed to implement orchestrations. As i started writing the response, it got rather long so i decided to make it a full fledged post. So here goes.
The way we designed the orchestrations was to hold composite large messages instead of multiple smaller messages and each orchestration would communicate with one or more webservices in the backend. So if we decided to, say, create a new ‘Business Document Application’, we would pass it customer information, department info etc and the orchestration would check if the customer existed using a lowlevel backend webmethod, create/update the customer, then invoke another interface to setup the document and so on. Some other orchestrations encompassed a set of ‘actions’ and data specific to them, such as ‘renew’, ‘invalidate’ etc in a single message and then called different backend services depending on the action.
Similarly search handlers acted as aggregators. Initially the searches were pass through orchestrations (and all the data was available from single webmethods in the backend) but as time has gone by some have been augmented with data from two or more sources.
If you dont have any composition/aggregation, then schema webservices would work just as well and perhaps we could have implemented the searches in this way – but i had some ‘preview’ of future requirements and decided to put in orchs early. With Schema webservices, I have been concerned about business level validation and returning SOAP faults etc from Schema ASMX’s and havent done a lot of probing in that area so i have been rather reticent to go with those alone.
It also depends a lot on the backend interface. For us we could use a solicit response port with a custom pipeline to set the soap operations/actions. In other implementations, for one of our backend systems we have had to call an external assembly (provided by the vendor to wrap their webservice operations) and this needs an orchestration (unless, maybe, we go down a custom adapter route and then a port would do just as well).
Schema webservices are also a good way to bring in a slim mediation layer initially and then beef it up with some orchestrations wherever necessary (if you can get the error handling sorted).
With all these of course, you must keep performance in mind and tune the receive and send portions of your solution accordingly. Some of the perf related material on MSDN and in the new deployment guide talk about settings which can help you tune the solution. We’re going to be taking a fresh look at the system and putting into practice some of the stuff we’ve been learning in this area so i’ll post more info as we progress.