I have been intently following a blog thread that was initially started by the “Other” David Chappell. David’s initial posting
SOA and the Reality of Reuse sparked a small flurry of responses, and responses to responses, which also include Joel McKendrick’s Pouring Cold Water on the Service Reuse. I tend to agree with most of the points made in David’s initial posting which includes -
- Reusable services can sometimes be hard to do
- Effective SOA reuse requires strong corporate wide organizational support with top management support and buy-in.
- SOA creates agility by allowing for flexible business processes, which if are configuration driven may be readily changed to suit the changing needs of the business. David argues that this can be a form of reuse.
However the overall tone of the threads seem to be casting a very strong doubt on the reality and practicality of service reuse at all. Some of the responses are flat out saying that service reuse is not possible.
So I went and compiled some information gathered from our customers who are building SOAs.
Because we have been shipping an ESB product for over 4 years, we have over 300 customers who are in the deployment phase with their SOA projects.
Without doing too much digging I came up with substantial list of reusable services which I will categorize as mediation services, on-ramps/off-ramps, business services, service patterns, and advanced mediation services
Mediation services -
- Data Transformation (XML to XML, text to XML, EDI to XML, etc).
- Data Enrichment
- Routing Services, whether static or dynamic based on content and context
- Splitter/Fanout - divide up an XML message into its constituent parts and send them to multiple destinations. This may be configurable using XSLT or scripting language.
- Aggregator
- XRef service. An impressive example of a reusable service is a cross reference service was developed and being used at Gillette. They have built a generic Xref service that is completely configurable and extensible by other groups using a web based configuration. The simplest function that the service performs is to look into an incoming XML message at a specific location based on an XPath expression, and replace the value at that location with another value as determined by doing a database lookup. It is completely metadata driven, is configurable to have multiple source and multiple targets, and access to multiple data parts using different XPath expressions. The database access is also configurable.
On ramps / Off ramps
These are specific services that used for the case where the application being brought into the SOA doesn’t support web services directly. They may be implemented as custom services, as a third party adapter, or provided by the ESB. This is just a partial list but you get the idea.
- FTP Service
- File Polling/Send/Receive
- Seibel access
- SAP ALE/iDOCS and RFC access
Composite Services
Any combination of business services and mediation services may be combined using business process definitions and exposed as composite services which can be built upon and reused.
- A unified customer view service is an example of a something that may be reused by call-center applications as well as customer facing portals. It may also be reused by payment processing applications. A unified customer view service may itself be a composite service that leverages multiple backend applications and data sources to gather or update its information about a particular customer.
Other Specific Business Service examples
- A financial services company has an HR service, which allows people to put in information about themselves to a database, such as their skills and their manager, etc. Other applications in other parts of the organization use the information. For example, the legal team uses it to route incoming work requests to the right staff based upon experience.
- A shipping company in South Africa has a “welcome” service. Any time they get a new customer, this service faxes information over to the new customer welcoming them, and providing them with information they will need to keep handy to do business efficiently (contact numbers, account info, etc.). This service is used by different parts of the business so that everyone interacting with the shipping company has a similar experience regardless of which part of their business they are a customer of.
- A reusable consolidated payment service for an insurance provider. The goal was to reduce the number of applications, streamline their business processes. Instead of 6-7 check payment applications they have just one. For each claim that is made they make a payment. However each insurance business is a little different - life from dental, etc. so the surrounding applications and processes that use the payment service need to be different. But in the end they need to cut a check or transfer funds. The consolidated payment service is that reusable service. It’s responsible for who gets paid, how the money is transferred, whether an explanation of benefits needs to be sent and how (email / paper), whether to consolidate checks for two benefits delivered at the same time, etc.
Advanced Mediation Services -
- XML Storage and Retrieval, whether through O/R mapping or direct native object storage and retrieval.
- Caching and aggregation of XML data across the SOA
- Complex event capture, filtering, and analysis, from streams of events originating from stock feeds or RFID readers and transforming into meaningful business events that can be routed to BAM dashboards.
Service Patterns -
Any combination of business services and mediation services may be combined using business process definitions to form reusable service patterns. If the ESB supports the notion of exposing the business process as a web service, then this in itself can become a reusable service.
- The VETO (Validate, Enrich, Transform, Operate) pattern is an example of a common pattern that can be reused across many projects.
- Federated Query service pattern and its related services
- A notifications pattern/service that allows notifications such as email etc to be raised when updates/queries occur across multiple back end systems, sometimes across multiple locations.
- Practically every Pattern in Gregor Hohpe’s EAI Patterns book can be implemented as a reusable service in a SOA.
And here’s the mother of all reuse -
Proflowers is the internet-based perishable marketing division of Liberty Media, whose other properties include QVC and Starz Entertainment Group.
Proflowers ships flowers directly from the growers around the world to the consumer’s doorstep. Because it bypasses distribution centers and retail shops, Proflowers cut their supply chain time from what is typically 12 days to 3. This means they have the freshest flowers: they are the only delivery service to make a 7-day freshness guarantee.
Proflowers initial SOA project was to use Sonic ESB to automate a time-based order processing system that is driven by the delivery date that the customers want their goods to arrive. They since have extended their SOA / ESB deployment to automate their whole supply chain globally. The thing that makes this the mother of all reuse IMO is that they were also able to duplicate their success by launching 3 new sister companies that use the same time based order processing systems - Cherry Moon Farms for fresh fruit delivery, Uptown Prime for fresh beef delivery, and Secret Spoon Sweets for fresh sweets and confections.
Dave
It mystifies me that so many would assert that SOA does not promote reuse if the service provides value for value. That the technical approach works is obvious. That the business model works isn't as clear. No free lunch.
The challenge is getting the value in return. A commoditized service tends toward an economic lagrange point: given a competitive service with equal value, the switching costs tend toward zero. Then the little differences make a big difference. Sustainability (a crucial part of the QoS evaluation) can be one of those differences.
Sort of a "d'oh" but a simple point worth remembering. Whether internal facing or external facing, service providers have to compete for value and it will be fascinating to see how that competition shapes up. SOA doesn't produce a frictionless system; one still loses energy having to keep the customers. It produces a low-energy transport system (as opposed to a Hohman transfer).
The economy stratifies by service types as you point out. For the content services, I suspect that protecting the sources for resources is one means and that does't augur well for the services that rely on user-generated content unless the 'greater fool' means keeps producing talented amateurs to replace the sources that are contractually obligated.
One has to question whether an organization has truly created an SOA if at least some of the services deployed into that SOA are not reusable/reused. If all we are doing is creating another technical layer and not providing more business flexibility in the bargain, we are doing a disservice to the organizations we work for, which after all do pay us to deliver business value.
One way to make that work is to combine service development with notification systems. The range from static service subscription to dynamic service composition is the unexplored country.
For businesses (as a type of service network) that require high QoS numbers and longcycle ticks for predicting results, the range is toward the low static side. For games or simulations (a just in time service network), the range can be quite dynamic.
What is missing is this range of just-in-time discovery and subscription.
All these young turks fretting over reuse. (sigh)
If you have worked in computer science as long as I have (35 years) you will have seen that "reuse" has been a holy grail in every era and always comes up short. Subroutines, functions, libraries, modules, classes, components, distributed versions of all of the previous, and now "services".
The problems are always the same:
* knowing how to make something reusable (which only happens with feedback from multiple attempts to reuse each particular component)
* knowing where to find components which are reusable, and knowing
what those components do (which means doing the detailed clear type
of documentation that never seems to get done)
* and most importantly, it is simply more easy (dare I say fun) to
develop from scratch than to find, learn, debug, refactor, existing
"reusable" components written/controlled by someone else.
* OH, and dont let me forget! People have the whole notion of "components" (aka services) backwards...FRAMEWORKS are what must be reusable and reused. Components dont exist! In the same way that donut holes dont exist. Frameworks are the donuts which define the holes/components. As long as people think about components in isolation, all of the above problems are made worse.