In previous posts here and elsewhere, I have talked about the the misconceptions around the "JBOWS" architecture (Just a Bunch of Web Services), which is often the early, and very incomplete, stage of service oriented architecture.
Nick Malik, a software architect with an integration firm, and a former Microsofter, wants to make it clear that having a plain old Web service (POWS?) is not the same thing as an enterprise-grade, SOA-ready service. Within an enterprise SOA, every service in the enterprise catalog should be automatically verifiable, and basic information can be collected and reported.
Nick lays out the following criteria to define the requirements for having a full-fledged, enterprise-ready, SOA kind of a service:
Keep it simple: "The service must be simple to call," Nick says. Do thye validation in your service, and avoid writing DLLs that create the data and then calls the service. With DLLs, "you customers still have a call-level interface -- iInstead of it being the service, it's the DLL. Nothing gained," he adds. Plus, "EAI components now need an adapter to call your service. Something lost."
Directly callable: "The service must be able to be called directly from EAI components, like Biztalk or your favorite ESB, without engaging an expensive or custom adapter Requiring an adapter means that you don't have a truly sharable service."
Include 'ping' and 'check' tools: "Services running at the enterprise level must have methods that can be called to validate that the service is running, and that downstream connections are valid. Nick suggests that every service should have standard methods for "ping" and "check."
Include infrastructure data: "Services running at the enterprise level should provide data about what servers, data centers, and support teams they are associated with, live and in real time," Nick says, suggesting that each service have a standard method for "GetSupportData" that returns a structure containing all the info.
Keep it asynchronous: "Services running at the enterprise level should normally be asychronous, with a very rapid return of an acknowledgement that indicates that the service itself takes ownership and responsibility for the message."
Correlate messages: "For async message exchange, the receiving side must send back the caller's unique ID, along with any unique ID it has created."
Standardize the call-back structure: This allows "any caller to easily construct the data needed for the receiving system to understand how to call the sender back with the response package."
Leave a comment