Service governance with middleware like ESB

, ,
1

The standard CentraSite installation contains asset types like Service to represent the published services and Application that represent service consumers. This way we can have a logical overview of the impact on consumers if we change the service.

However, when we get into the physical details the picture can be more complicated. Here we might have some intermediaries involved as the service request from the application travels its way through the network and eventually hits the actual module that implements the business functionality for the service. E.g. the business functionality is implemented in a COBOL module running on mainframe (z/OS). The functionality is made accessible as a service via Microsoft Host Integration Server (HIS) and this service is exposed on the ESB say Microsoft BizTalk to add role-based security. Thus the service request travels like:
Application => ESB => HIS => COBOL module

Logically it is the same service, but physically we can see 3 endpoints probably on 3 different servers: the ESB server, the HIS server and the mainframe.

For the COBOL developer it is highly relevant to see that changing the COBOL module will have an impact on the HIS module, which in turn impacts the exposed service on the ESB and finally impacts the application.

The ESB could add some transformation to improve usability of the exposed service e.g. beautifying the XML instead of just deriving it from the COBOL copybooks. It could even do service aggregation to expose more coarse grained services. In such cases I would argue it is a different service that consumes other services.

Does anyone have experience on good practice for setting up governance for such cases?
Would you register multiple instances of the service in CentraSite though they only differ on service address?
How do you handle that different groups are responsible for the different endpoints because you have different competences to do COBOL development compared to ESB development/configuration?

Any advice is highly appreciated.

BTW. We use ActiveSOA and thus we have added a Module asset type to register the COBOL modules.

2

In my experience, it very rare to see functionality from a core system - an ERP or a home grown COBOL app - exposed as is as a service. Some level of transformation, aggregation, re-factoring always happens before the functionality becomes a service and is invoked by a service consumer. As a result, I would recommend tracking each component along the way as a separate instance of service, or even instances of different asset types.

In your case, you could set up separate asset types for Service and COBOL modules and tracking relationships among them.

Another argument for this approach is that the ‘Service’ asset should be consumer-oriented. What is behind the Service is not relevant to the consumers. The endpoints exposed to the consumer should be the one that they are expected to invoke.