Web services and business services are two hot topics today, but many companies fail to appreciate the difference....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
As a result, they can fall into a nasty trap, particularly mainframe-oriented companies.
A Web service is a piece of business logic that can be invoked and executed in a standard fashion, using Simple Object Access Protocol (SOAP) as a communications protocol and Web Services Description Language (WSDL) as the specification language.
A business service is a reusable combination of IT components that delivers a business-oriented service -- for instance, "Get Customer Details" -- to the caller, at the same time shielding the caller from any of the implementation details of that service. At first glance, these two definitions seem awfully similar, but the key difference is the choice of granularity of the two types of services.
To illustrate, imagine a company that has decided to implement a business service-oriented architecture (SOA), using Web services as a way of accessing mainframe programs. This company has three CICS applications used when gathering information about the customer:
The natural tendency in a Web services-based SOA might be to turn the applications into three Web services -- WS-A, WS-B and WS-C -- because there is a tendency to keep Web services to the smallest possible size. Now when an application external to the mainframe wants to get customer details for a particular customer by name, the application is changed to carry out the following procedure:
Although manageable when the number of services is small, this approach will cause real problems in the future.
First, three sets of WSDL will have been created for the three services. Second, since the CICS transactions will almost certainly expect data in non-XML formats, there will be six XML mapping operations -- three to map input XML into the desired format for the CICS applications and three to map the responses back into XML. Lastly, the calling application has to understand the procedure to obtain the customer details. This will make future changes to the individual components difficult since if the procedure were to change, the calling application would have to change, too.
As the number of services grows, these problems will increase in severity. XML is verbose, and this fact combined with the mapping needs can cause performance and scalability issues. Managing all WSDL is a headache, and the increasing lack of flexibility of the implementation will prove a major inhibitor to delivering business agility.
Instead, consider a more business service-led approach to the problem. If the likely business service required outside the mainframe is to gather the customer details in full, based on supplying the customer name, then creating a single Web service will be a much more appropriate level of granularity for the implementation.
The calling application would call the 'Find Customer Details' Web service, supplying the customer name and receiving back all the customer information. An intermediary, orchestration capability would be required to understand the CICS application flow required to execute this service, but there are tools on the market that can supply this function.
One immediate result is that there is only one copy of WSDL required for the single Web service, and only one pair of XML mappings to map from XML to the CICS format and back again. Not only is this more efficient in resource consumption, but it limits the management headache of the proliferation of large numbers of Web services.
The second result is that the non-mainframe application programmer does not need to have any knowledge of the mainframe-based implementation procedure. The fact that Application A has to be called with the customer name and yields the customer number, which is now input to Application B and C, is hidden from the caller of the business service.
Getting the granularity of business services right is something best done, as with all architectural design, at the start of a project rather than at the end. Simply turning all mainframe applications into Web services is an approach that can cause serious problems in the future. Mainframe companies should consider the question of granularity carefully if they are to avoid losing all of the flexibility that a disciplined approach to integration can provide.
Steve Craggs, European chairman of the Integration Consortium, has been involved in the business integration marketplace for more than 10 years. He ran the MQSeries worldwide business for IBM and more recently was the founder of U.K.-based Saint Consulting.