Architect Consultant blog

I was wondering what kind of protocols/mechanisms/standards are used to establish reliable Services? Just to get started: * HTTP But this is by definition not reliable so some extra mechanisms are needed on API level. * JMS (Queues or Topics)? Is reliable but only used within Java technology. I like the Topic idea so that other components can listen on the Service entrance. * WS-ReliableMessaging It's a standard defined on top of SOAP, but which tools, platforms already use it? * Other? I am curious in your experiences!

I came accross this article about managing transactions within a SOA environment. There Vinay Singla mentions 4 techniques: 1) Perform the operations that support transactions before the operations that don’t support transactions (technique 2 can help) 2) Use compensating transactions (services must support compensating capabilities) 3) Break the transaction into multiple decoupled transactions 4) Execute the transaction as a long-running transaction Maybe you think of WS-Transaction and WS-Reliability but these standards have not yet been mature enough. Another technique not mentioned is the use of Functional/Technical maintenance. In this case when a step is not fulfilled, it will be send to a queue. This will be picked up by maintenance to correct the problem. I always fancy the most simple solution that decreases complexity for situations that may occur only once in a while, but this depends of course on the requirements.

Are you looking for SOA examples? Maybe you can find them here .

Here is an interesting post from Chris about dynamic transformations within the OSB. It looks great, but think about this: You loose the strong typing of the messages the proxy can receive (as described in the blog itself). This may lead to faults that are difficult to trace because the service contract is in fact far more coarse grained. How about maintenance? I like the approach that for a different major version of a service with different XML data, use a different proxy. This way services of different versions can live together and services can become obsolete when clients are no longer using the old service. If you try to put all versions of the service in one proxy service it can soonly become unmanageable. But it can still be useful to have dynamic transformations.

This week I had a discussion about a federated ESB and functional domains. It is widespread known that a CDM within an enterprise is hard to achieve and that's why the enterprise is divided in functional domains. However a common mistake often made, is that this division is done on a 1-by-1 mapping to the organisational divisions. Reasons I hear: * "Then we can make this department responsible for those processes" * ".. and those department is responsible for those systems/applications" This again is the silo-based concept of thinking. This division is furthermore also visible in the division of domains within the IT landscape (federated ESBs). But if there is one variable that often changes it will be the organisation. Also most processes will span multiple areas and it is very difficlut to keep that in one domain. However the business of the organisation and the functions the business must offer is more stable. So divide your SOA landscape on a functional basi