The Long Tail of Services 
Commentary--The "Long Tail" moniker has been used extensively (some would say overused) in marketing and mass media over the last couple years. Now, as different use cases for SOA evolve, the metaphor seems appropriate to explain the growing use of services outside of the core domains of SOA, business process implementation and integration.
First, lets take a step back. The term long tail, coined by Wired Editor Chris Anderson, is used to describe how companies like Amazon, iTunes, and Netflix have monetized the huge number of low-volume products they carry in inventory. While traditional retailers make most of their money selling only the blockbusters, these companies have discovered how to make significant money from the products that sell in very small quantities. In The Long Tail diagram below, the green area (the head) represents the blockbusters, a small number of high volumes sales items.
The yellow area is the tail, representing a large number of items selling at very low volume. You can imagine that if the tail is long enough, its revenue is significant, and can even exceed that of the head.
The Long Tail
The Long Tail of Services
The phenomenon of minimalist services created for singular purposes wont subside anytime soon. In fact, single-use and low reuse services, common in Web 2.0 applications, may outnumber those designed for reuse. Does that make minimalist services less valuable than those that may be reused? Not at all.
As Web 2.0 and SOA evolve, the Long Tail metaphor is appropriate because it helps justify the phenomenon of minimalist services created for singular purposes. While the SOA mantra is to create services for reuse, the rise of Web 2.0 technologies like AJAX and Flex has created a different niche for the development of services, resulting in a style of service that is not very service oriented.
In The Long Tail of Services diagram, the horizontal axis represents individual services, and the vertical axis shows instances of use. The head area represents services that are reused many times. The tail area shows services with ever decreasing reuse, culminating with services used only a single time (single-use services).
The Long Tail of Services. Single-use and low reuse services may outnumber those designed for reuse.
Services for Web 2.0 Applications
Building services for consumption in a user-facing application (Web 2.0) is quite different than building services to feed core business processes (SOA). If you download and use any of the AJAX-like environments, or Adobes Flex, and build a sample display fed from XML data, youll likely notice the XML structure tends to follow a simple, almost table-like structure. This is very simplistic compared to the information-rich XML structure you might expect in real-world business objects like a purchase order, invoice, or insurance policy. The latter are the domain of SOA proper, the subjects manipulated by services while moving through business processes.
At first glance, I would say the Web 2.0 style services are high-quantity, commoditized, point services fulfilling a specific, singular purpose. Dont expect reuse from these, as they were not designed with reuse as design criteria. But thinking further about this, I now feel that a small service like this may actually be a good candidate for reuse. The reason: its visualization is the main manifestation of its existence. In fact, a user who sees the visualization of the information is probably going to be the one to recognize that it can be used in other situations. Isnt this a much more powerful reuse driver than a UDDI query, or worse, a WSDL file sitting on a web server or file system somewhere? Even with a nice WSDL viewer, it takes imagination to envision the data reused in another application. If this visualization aspect does turn out to be a big factor in reuse, perhaps that will drive a movement to publish services with default visualization components. It sure makes sense to be able to visualize a data structure in a display composition, rather than simply viewing an XML structure.
Other Aspects of The Long Tail of Services
The Long Tail of Services diagram is also a good context to help rationalize other aspects of service oriented design. I can envision where on the graph you would expect to apply the most governance energy (services whose intent is high reuse), and where you might expect to use light-weight REST or POX rather than SOAP as a delivery mechanism (in the long tail). Debates such as REST versus WS-* are still simmering, but The Long Tail of Services may at least provide a different dimension on the discussion, providing a context where one point of view makes more sense relative to one section of the curve.
Credits: The Long Tail picture was created by Hay Kranen/PD, and annotated by me.
biography
Kirstan Vandersluis founded XAware, Inc. in 1999. He has spent more than 20 years designing and implementing software systems.
Original: news.zdnet.com
No comments:
Post a Comment