In the most pure and simple service oriented scenario, a single consumer interacts directly with a single service provider.

For more complex situations, intermediaries are used to provide additional capabilities:

• Security
• Transactions
• Routing
• Data Mapping
• Interface Mapping
• Reliability
• Protocol Translation
• And etc…

What exactly is an intermediary?

An intermediary is a piece of hardware or software that bridges the gap between a service provider and service consumer to provide one or more value-added capabilities (see bulleted list above). There are three primary options for intermediaries (and a host of variations on these three themes):

• Service Intermediary - Another service acts as the intermediary, providing required enterprise capabilities
• Centralized Bus - Service calls are brokered through a common, centralized focal point
• De-centralized Framework - Enterprise capabilities (security, mapping, etc.) are pushed out to the endpoints

Comparing the three options

As with so many things, there is no clear-cut winner across these three strategies, it all depends upon what you are trying to accomplish.

Option 1: Service Intermediary 

Advantages: Extremely lightweight solution.

Disadvantages: Not as robust or flexible as other approaches and requires more testing to verify proper configuration.

Option 2: Centralized Bus

Advantages: Offers lots of “out-of-the-box” capabilities that are pre-configured and available for use.  Provides a single point of control and service access management.

Disadvantages: May be over-kill in many situations, offering far more functionality and options that are needed.

Option 3: De-centralized Framework

Advantages: Provides the greatest flexibility and configurability for managing endpoints and enforcing policies.

Disadvantages: Requires a more disciplined governance process to ensure that each service is managed properly.

Working with intermediaries

Services do not generally need intermediary support except to provide value-added capabilities such as security, transactions, routing, data/interface mapping, guaranteed delivery, protocol translation, etc.  It is important that organizations carefully evaluate their requirements and select architectural strategies that meet their needs.  There are a variety of valid topologies that could be employed, depending upon your requirements, including services as intermediaries, deployment of a centralized bus (either physical or logical), and the utilization of a decentralized, policy-driven framework (“liberate the endpoints”).

The structure of data for your service operations is very important.  This is the primary way that information is transmitted within a service oriented environment.  Moreover, the data model that you use for services will largely dictate service compatibility, interface flexibility, and to some degree will determine the extent of interoperability challenges that you will have as your service catalog expands.

One effective technique for defining the schema for services that I have seen is something I describe as a composite schema. There is a rather large assumption that many service designers make, which is that the schema definition for a service must be atomic.  That is to say that you either define the entire schema inside the service interface file, or define the entire schema in a separate file.  This is fine for the first few services, but what happens if you are six or nine months into service orienting your enterprise and a key aspect of your data model changes (perhaps the ‘customer’ element or ‘product’ element)? You’ll have to go and update the schema for each and every service that uses these elements.  The alternative, is to wrestle with each service design team and get them to agree to a single schema that everyone uses (which becomes bulky and unwieldy).  The answer to all of this, is a composite schema.

A composite schema is one that draws its definition from more than one schema file.  Thus a service interface has some of its data elements defined within one schema and some defined within another (some choose to have a single schema per service interface and simply have that single schema file reference several other schema definition files).  This allows service definitions to be reused and common elements to be defined only once.  When changes inevitably need to be made, this keeps the maintenance overhead to a minimum.

So what should the design of this composite schema look like?  There are several possibilities, but a common approach is as follows:

• Core Data — This schema defines common elements that are consistent across the board within your enterprise.
• Division / Line of Business Data — The next layer tends to focus upon some major segmentation such as industry or business division, etc.
• Product or Service Line – Data structures that are common across a product line or service category are defined in this schema.
• Service Data — Unique elements that are specific to the service are defined here.

Obviously, you could define as many or as few categories of schema as you like.  The goal here would be to minimize how much of a service’s data elements are defined as service-specific data types.  The ideal, would be for 80% or more of the data used within your service interfaces to draw from common, reusable schemas.

Composite schema are by no means revolutionary.  This is a capability that has existed for years.  The problem, of course, is that there is a tendency to craft solutions in a traditional, silo-oriented fashion.  Service orientation drives us to think more about exposing and consuming services across business units, in the broadest possibly context.  It also drives us to compose solutions from existing assets before creating new assets.  All of this leads to a need to work smarter, not harder, and look for opportunities to reduce maintenance costs and more effectively utilize resources.  Composite schemas represent one such technique.

Immediately after the conference last month, I got caught up in vacation and then working with a couple of new clients.  I’m back in the saddle now, and wanted to share some of my experiences.

The SOAWorld conference was very well attended, including the co-located events: Virtualization World and Data Services World.  I was a bit suprised to see that so many of the presenters were vendors rather than customers or practioners.  If this had been my first SOA conference, this would be a red flag for me that SOA is still just a lot of hype.  As it was, I just found it rather odd and a little more of an empty experience than I have come to expect.  Otherwise, the conference was great and it was quite encouraging to see so much energy around things like SOA and Virtualization in spite of the state of the economy.  This gives me great confidence and reinforces a belief that I have held for some time now, which is that SOA and Virtualization make good economic sense.

My portions of the conference went fairly well.  On Monday, June 23rd, I delivered: “A Composable Service is a Good Service”.  The room was packed and that presentation was extremely well received.  The audience was very engaging, shared some of their own war stories and asked for insight on particular service design dilemas that they have been dealing with.  On Tuesday, SYS-CON staff contacted me and asked if I would be willing to step in for a speaker that would not be able to attend.  I accepted, and delivered: “A Little SOA Goes a Long Way” (my SOAWorld presentation from last November).  I also had the pleasure to participate in two expert panels, one of which was held in the Reuters studio in Time Square.  When one or more of those videos become available, I’ll be sure to provide a link.

Presentation deck downloads: “A Composable Service is a Good Service” (PDF)  and “A Little SOA Goes a Long Way” (PDF)

One final comment about the conference is that there was quite a bit of buzz about virtualization as well as “cloud computing”.  I’ve paid a little bit of attention to the virtualization movement, but thus far I have completly ignored cloud computing.  None of my clients are talking about it, and it may all be vaporware (let the cloud-related puns ensue), but it has sparked my curiosity all the same.

Up until now, there has been such a rush to roll out initial SOA services and supporting infrastructure, that little attention has been given to what good service design truly entails.  This is a natural evolution that must occur with any technology or methodology.  Throughout this summer, I plan on releasing several posts regarding proper service design.

Initially, I would like to focus on the subject of ‘composability’.  Composable services have several important qualities:

• composable services stictly adhere to their service interface, Service Level Agreements(SLAs), and supporting metadata
• service operations always leave enterprise data in a valid business state
• service operations can be called indepently, in parallel, or as a part of a larger service orchestration
• service operations can be called within or without a transaction context

When you boil it down to the essentials, composable services clearly define what they do and they do exactly what they have defined.  Consumers of composable services are then at liberty to determine how they want to use that service’s operations, rather than the service having certain built-in assumptions regarding how the service will be used or what the larger business context ought to be.

To learn more about the merits and details of composable services, I recommend the following resources:

• “Composable Services” (MSDN Library)
• “Service Composability” (SOAprinciples.com)
• “A Composable Service is a Good Service” (Presentation at SOAWorld 2008 next week)

There’s another, less tangible benefit of composable services — they are lower stress.  The frustration and stress associated with consuming a service that later fails due to some unknown buisiness logic violation is supremely frustrating.  Consuming services that are not composable is stressful, because they cannot be depended upon to work in whatever context you choose.  Likewise, publishing non-composable services for consumption is stressful because the service provider is constantly in fear that someone will ‘misuse’ a service.  This is no way to run an enterprise or encourage the adoption of service orientation. 

I’ll explore all of these topics next week in my presentation at SOAWorld on composable services.  I’ll post the completed presentation as well as perspectives from the audience next week.  Have a great weekend and I’ll see you in New York!

The first day of SOA World 2007 - West went very well. Miko Matsumura with Software AG / webMethods kicked things off with the keynote - Time Oriented Architecture: Evolution by Design? And he had some really entertaining 3-D animation and virtual simulations in his presentation. It was pretty cool. The next presentation in the main room was by Theo Beack from BEA - Virtualized SOA: Adaptive Infrastructure for Demanding Applications.

I delivered the third presentation of the day in the main room - A Little SOA Goes A Long Way, discussing the importance of identifying which aspects of your enterprise are ripe for service orientation and which areas are better left alone. The outline for that presentation is as follows:

• Introduction
• Why SOA initiatives fail
• What my kids taught me about SOA
• Adopting SOA selectively
• Bowling for governance
• Review

This presentation seemed to be well-received and I was particularly pleased with the broad acceptance of the Selective SOA Methodology that I presented. This methodology serves as the cornerstone for much of the SOA Adoption and SOA Governance mentoring that Web Age Solutions provides to clients. If you’d like a copy of the presentation, you can download it here — A Little SOA Goes A Long Way (PDF).

After a trip to the Expo Floor and some snacks, we were back in the main room to hear from Mike Pellegrini from Active Endpoints presenting - Your SOA Needs BPEL For Orchestration. He had some great content, but one nugget really stood out to me early in the presentation. Mike was describing services and processes as two kinds of abstractions that are important in SOA. After discussing them separately, he offered the following synthesis: “Services don’t change often, but they are orchestrated and re-orchestrated fairly often to build/modify business processes.” I like that. I would qualify it to say that services SHOULDN’T change often. In other words, I believe that this is indicative of an enterprise that has reached a considerable degree of maturity in their service orientation. Nonetheless, I thought it was a really solid characterization of services and processes.

Following Mike’s presentation, the speaker that was slated to speak in the main room could not be located. After hunting for about ten minutes, SYS-CON got desperate and accepted my offer to deliver another presentation that I had on my laptop. So I hopped up on stage, grabbed a mic, and fired up my laptop with the same presentation that I had delivered at SOAWorld in June early this year in New York - Service Oriented Patterns and Anti-Patterns. Fortunately, I had delivered that presentation about a month ago for a users group in Dallas, so I wasn’t completely unfamiliar with the material. I was a little rushed for time due to the late start, but overall that presentation went rather well.

After a lunch break, Ian Thain of Sybase presented - Model-driven SOA. His presentation included some interesting demonstrations of model-driven SOA using Sybase tools. Next was another Expo Floor break and snacks, followed by the SOA Power Panel.

I had the pleasure of participating on the SOA Power Panel along with Miko Matsumura (Software AG / webMethods), Kevin Hakman (TIBCO), and Sandy Zylka (NextAxiom). Jeremy Geelan moderated and we had some great discussion around SOA, convergence with other trends, economic impacts, and more. The panel session was recorded and I will post a link to it once it is made available.

I don’t know what happened for the rest of the day as I was occupied by various discussions in the late afternoon and then in a bit of sight-seeing in the evening (Coit Tower, Treasure Island, Lombard Street, and more).

I delivered my presentation today at SOA World — Service Oriented Patterns and Anti-patterns. The talk covered business interaction models, technology patterns and anti-patterns, and human patterns and anti-patterns. We were stuck in Sutton Suite, which is on the second floor and rather off the beaten path. I thought that the location might deter attendance, but to my surprise, the session was packed. Every seat was taken, the back of the room was full, and the audience spilled over into the hallway. The session seemed to be well received and we had some discussion around the topics as well. I hope that more work is done around the subject of patterns for service orientation. I definitely think that the OASIS Reference Model is a good start. I may take an opportunity to post my thoughts on that another time.

For those of you that were able to find the room and attend the talk, thank you so much for providing me with an opportunity to speak with you. I enjoyed it and I hope that you got something out of the session.

If you would like to browse through my presentation from this afternoon, you can download it here: Service Oriented Patterns and Anti-patterns (PDF)

I got my acceptance e-mail from SYS-CON for the SOAWorld 2007 event in New York City. I’ll be presenting “Service-Oriented Patterns and Anti-Patterns.”