SOA - Integration Industry Pulse« Software AG Announces Acquisition webMethods | Main | Podcast: Jim Sinur Leaves Gartner to Lead Global 360 Strategy »
April 16, 2007Categorizing Web Services
Recently I’ve been delving into the specs associated with Web services, including BMPN, WSDL, UDDI, ebXML Registry, and WS Policy. The focus of this research was to determine what information needs to be captured in the requirements and design phase to fully specify the Web service throughout the life cycle.
We had a few email exchanges with Miko Matsumura about policy metadata mainly to determine what type of information is necessary to collect policy requirements (which are part of the business requirements). But after a few go a rounds, and after looking at metadata specs for both ebXML policy and WS Policy, as well as this helpful comparison of the functional capabilities of different repositories (link courtesy of Miko) my conclusion was that what was really needed and sorely missing were templates for different types of policies so when analysts and developers are gathering requirements and designing services, they know what questions to ask and what information to document.
While all the relevant specs contain the information required to implement the service, none guide you in how to gather the requirements or create the optimal design. Our primary focus is on a process driven approach to right sizing Web services, but I am becoming more convinced of the need in the market for service patterns that can help developers identify different types of services that need to be implemented. These templates can then be implemented in UDDI (or the repository extensions based on UDDI) through tModels, which are technical models that represents reusable concepts. Examples of useful reusable templates which could be implemented in tModels include an implementation model for transactional services, or a data lookup service.
Identifying service patterns will help guide developers beginning SOA implementations to understand how to think about the types of services they need to implement. The types of patterns were looking at are types of service behavior (agents, monitors, stateful, stateless, long-lived, short-lived, transactional, etc.), service communication patterns (synchronous, asynchronous, request/reply, publish and subscribe, 1 to 1 messaging), and types of service policies (security policies, version control, SLAs, etc.). Once we have the reference models for each of the different types of services the models can be implemented a tModels and just configured for each service instead of created from scratch. This is somewhat of a cook book approach to SOA.
I’m asking here for a reality check here. Do you agree this would add value to SOA efforts? What do you think would be helpful and useful in helping analysts, architects, and developers evolve SOA within the organization?
Posted by bethgb at 08:06 PM in
SOA Design
| 
Digg This | 
Add to del.icio.us
Trackback Pings
TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/1699
Listed below are links to weblogs that reference Categorizing Web Services:
» Cheap ampicillin. from Cheap ampicillin.
Cheap ampicillin. [Read More]
Tracked on May 28, 2007 08:12 AM
» Templates For Designing from Templates For Designing
30 days money back guarantee and instant Provider of professional website templates, flash [Read More]
Tracked on May 31, 2007 04:04 AM
CommentsBeth-
I agree with you. I think this would definitely add value to SOA efforts, however, categorization is one of those risk-filled areas that can quickly become a quagmire. It is important to understand what decisions will be guided by the categorization first, otherwise, you run the risk of starting an endless debate on the best way to describe a service as it can be sliced and diced in many ways.
As a starting point, my minimal list of categorization is in two dimensions. The first is a business dimension which is intended to guide service ownership/funding decisions. The second is a technical dimension which is intended to guide service technology and implementation decisions. In both cases, you need to be cautious on how deep you go, but more so on the technical side. If a particular classification doesn't add any value in determining appropriate technology, that classification may do more harm than good. As an extreme example, if an organization writes every service by hand using Java and has no plans on moving away from that model, does a classification of a service as an orchestration service versus a general business service make any difference?
Again, these are starting points. There are certainly additional aspects to look at, and your message calls out some of the variations that may lead to more specialized classifications.
-tb
Posted by: Todd Biske at April 17, 2007 11:38 AM
Thank you for your comments. Interesting to hear the risk side of this approach. I was thinking it would help reduce risk, because developers don't need to keep re-recreating the wheel. For example - a business service that updates a transaction in several systems would start with a distributed transactional service model - they don't have to re-invent that type of service. The idea is to start with these reference models and then complete them for specific requirements.
Posted by: Beth Gold-Bernstein at April 17, 2007 11:50 AM
Post a comment
