The Long Tail of IT

In these days of recession and shrinking IT budgets, development groups are forced to do more with less. This appears to be an opportunity for growth for Open Source projects, as companies find it difficult to purchase products, or even expand use of products they currently own. Open source products are available to assist in implementations of a wide range of IT problems. And with a very low cost of entry, development groups can kick the tires, and even implement an entire project, without awaiting the decision of an enterprise architecture group or budget committee. In a recent meeting with AMR Research, analyst Dave Brown talked about “Long Tail” effects within IT, where large, mainstream projects are still getting funding, but the large number of smaller, tactical projects are left to fend for themselves. This is exactly where Open Source can make the biggest impact… the large number of tactical projects going on within a company, often “flying under the radar” of the corporate enterprise architects. And it is not just the stealth projects benefiting from Open Source. Many projects designated as “tactical” or short term solutions have the flexibility to select the most expedient solution, which often turns out to include Open Source. I discussed Long Tail effects in the creation of services here.

So, in addition to areas where Open Source has a solid beachhead, like Linux usage for corporate servers, it certainly appears that Open Source is making additional headway, filling many nooks and crannies in the IT development space.

SOAWorld

This fall’s version of SOAWorld ran November 19-21. I attended all three days, and presented a session on creating and managing data services for both SOA and RIA environments. The show was a combined conference that also included the named conferences Cloud Computing World, Virtualization World, and Data Services World. David Linthicum gave the keynote address on Wednesday, with a theme of “its time to make something work”. The hype is officially over, with 53% of companies now having SOA up and running. As an industry, we’ve proven SOA works if you approach it right. He reiterated several concepts he’s conveyed in the past, such as “SOA is something you do, you can’t just buy it”, and “understanding your data is key to success”, and “data is the foundation of SOA”. Architects should apply a layered approach to data, with an abstraction layer over the raw data sources, and services then binding into the abstraction layer. David spent a good portion of his presentation outlining a full SOA process that he helps clients implement. To summarize, if you follow the right process, SOA works.

Some other interesting thoughts and ideas from the show

Paul Lipton from CSC warned about ensuring governance is in place fairly early in an SOA initiative. Once your services are reused, you risk becoming a support group, so you need to implement a plan for reuse and support.

Michael at Active Endpoints had an interesting presentation on Complex Event Processing, which I wrote about here.

Werner Vogels, CTO at Amazon, gave the Day 2 keynote. He spoke about Amazon’s cloud infrastructure for both storage and processing capabilities, and noted that many startups are using these services to gain scalability for very little investment. He likened the cloud infrastructure business like early 20th century Belgium brewing companies. At that time, each brewery had its own power plant. Power companies centralized this infrastructure, freeing brewers to concentrate on their core business. Computing infrastructure seems to be following the same path. Vogels also revealed Amazon’s deep adoption of service orientation, noting that a typical web page on Amazon.com involves the invocation of 200-300 services to build the page.

Dr. Michael Carey, who formerly led much of the development for BEA’s Aqua Logic, described some of the major design concepts in Aqua Logic, which map fairly closely to the capabilities of XAware. One primary goal of Aqua Logic is to create a data abstraction layer, and expose data, wherever it resides physically, as “entity” services. Business information objects, like a customer, order, or invoice, is represented as a service, with multiple operations to read, write, update, and delete, as well other more business-centric operations like “process order”. Without this entity service layer, orchestration is very difficult, as every data access invocation requires multiple calls. Carey made a compelling case that any composite app built on services requires an entity service layer.

Rob Steward of Data Direct discussed Data Direct’s SOA Data Access tools. Like Dr. Carey, Rob discussed the need for a data services layer, and provided a definition of data services that included abstracting physical location away from the logical model, ideas that are core to XAware as well. Rob described typical client application operations in terms of queries into a data services layer implemented by Service Data Objects (SDO), which are then manipulated, possible off-line, then updated back to the services layer.

Jeff Davis of HireRight, Inc. gave an interesting talk on his company’s services implementation using Apache Tuscany, which is a framework for implementing the Service Component Architecture (SCA), which allows services to be defined once, and invoked over any supported transport. HireRight is mainly using JMS as their channel to invoke services.

Glen Daniels of WSO2 spoke about their company’s Registry product, and the influence of social web site features on its design. The registry manages access to service definitions, and provides social features like ratings, comments, and labeling. I thought this tack was interesting, because I believe the main reasons software reuse has never been what it should be revolves around human trust issues. Can you trust the developer or his code? Who else is using it that you might talk to? If you trust the developer (based on a high rating), and a component is used by others with good reviews, then you are more likely to use that component. This registry product includes core features common in most web 2.0 and community sites, to increase the trust factor, hopefully leading to better reuse.

While this is just a sampling of the sessions I attended, it does represent the most interesting of the bunch in my mind.

Complex Event Processing

At SOAWorld in San Jose last week, I attended a session by Michael Rowley of Active Endpoints, covering Complex Event Processing (CEP), another TLA (three letter acronym) that is getting some press these days. This was my first real exposure to CEP, so I’d like to briefly share my thoughts on it for others not familiar with it. CEP is a smart way to associate events in the enterprise. A typical scenario is credit card processing fraud detection. While listening on an event stream of credit card authorizations, you might want to know if the same card was being used at 2 different physical locations at roughly the same time. That’s a good indicator of fraudulent use. CEP generally provides a query language, similar to SQL, but extended to deal with events. The primary new dimension queriable with CEP is that of time. For our fraud detection case, we might query for any credit card authorization occurring within a 15 minute window where the distance between physical locations is greater than 15 miles. An engine processing such a query would listen to the event stream, and send a notification each time a match is found. Thus, alarms are generated for potential fraudulent use.

CEP is a natural fit with business process management, like Active Endpoint’s line of BPEL engines. For those that don’t know, Active Endpoints is a partner of XAware, as data services created in XAware fit nicely as the data layer in a BPEL process. With Active Endpoint’s integration with CEP, events are automatically generated for each step in a BPEL process. Then, the CEP query language enables operators, analysts, and developers a means to easily and flexibly evaluate the event stream, identifying important trends or critical compositions of related events. This really seems to be a neat technology that I think will gain traction in the future.

For further investigation, I'd recommend looking at the Esper project, a commercial open source project located at http://esper.codehaus.org/.

Services for RIA

Last week I presented a session at AJAXWorld 2008 in San Jose, titled “Hands On Data Services for RIA, WOA, and SOA”. While the “hands on” part was a demonstration of the XAware technology, where I showed building a data mashup from text data logically linked to a database, the first half of the presentation was a discussion about the key role of data services in Rich Internet Applications (RIA), Web Oriented Architecture (WOA), and Service Oriented Architecture (SOA). Data is almost always at the heart of an application, thus finding appropriate ways to get data to an application is a key part of making a software system work. Since I was at AJAXWorld, where RIA was all the buzz, I focused the importance of data service in an RIA environment.

The idea of using a services layer to supply information and operations to a web client application is not new. While I’ve written about the combination, I certainly am not the first to recognize the nice fit. Some of the acronyms floating around the internet, and the AJAXWorld conference were SOFEA (Service Oriented Front End Architecture) and SOUI (Service Oriented User Interface). SOFEA was coined by Ganesh Pradad and a couple coworkers in October, 2007, in a paper titled “Life Above the Service Tier” (http://sofea.googlegroups.com/web/Life+above+the+Service+Tier+v1_1.pdf). Ganesh’s blog (http://wisdomofganesh.blogspot.com/), which is high on my favorites list, contains additional information and resources.




SOFEA recommends a clear separation of presentation tier concerns. The major processes involved in the presentation tier are:

1. Application Download phase
2. Presentation Flow – driven by client side
3. Data Integration – use the service tier, peer-to-peer (allowing two way communication like notifications). XML based using REST or WS-*.

By separating these concerns, each can be optimized for its special needs. Whereas traditional thin-client technology requires the server to be involved in all three concerns, the rich capabilities of RIA no longer require that. In addition, the data integration piece can take advantage of an existing services layer, that is likely already built or under construction within the enterprise. Ganesh also claims that the Front Controller pattern, used in all the server-based web development frameworks, is actually an anti-pattern, made popular simply because of the previous lack of capabilities on the client side. The existence of so many frameworks supports his point, as none of them seem to quite satisfy the needs of the presentation layer. They never will, according to Ganesh, because, among other things, placing portions of the presentation flow logic on the server violates the principle of separation of concerns. Encapsulating presentation flow fully on the client side is now possible with the quickly maturing RIA development environments.

SOUI shares a very similar architecture. Proposed by Nolan Wright and Jeff Haynie (who founded Appcelerator on this principle), SOUI also places presentation flow logic on the client side. The major difference between SOUI and SOFEA is the preference for JSON in SOUI. JSON is more compact than XML. But the advantage of XML is the better typing system (elements and attributes can be strongly typed), along with validation tools built in.

The XAware project appears to be a very viable candidate to fill the gap of the data integration piece within SOFEA and SOUI. The environment is well-positioned to create information-rich services to supply data to the presentation tier. As we continue with project development, we will be adding more support material and features to make it even easier to use XAware for RIA development.

RIA at AJAXWorld 2008

I attended AJAXWorld 2008 in San Jose last week, where I sat in many sessions and also presented a session myself. It was a good and interesting show, focused mainly on Rich Internet Application (RIA) development technologies. While my day job usually has me dealing with back-end server, data integration, and data services issues, it was a refreshing change of pace to look at what is happening on the user-facing side. I’ve always had a thirst for building user-facing applications, and as you would expect, the attendees as a whole share that sentiment. Paraphrasing the words of Jeremy Grelle of SpringSource, one of the beautiful things about user interface development is the immediate, visual feedback you get during the development cycle. You make a change, hit refresh on the browser, and voila, you see your change. I’d like to share just a couple tidbits I picked up at various sessions:

Jeremy Chone of Nexaweb, pointed out the different target markets for UI development, the consumer market (think Google.com, Yahoo.com, MySpace.com), and the corporate market whose users are employees of a company. The consumer market demands the most polished and engaging experience, because users are surfing on their own time, and generally pick the site that’s most enjoyable to visit. The corporate environment, on the other hand, focuses on productivity. Users want to get their job done quickly and efficiently, so they can go home on time after a successful workday. Consumer apps must scale in terms of users. Companies must scale in terms of the number of applications that will help automate business processes. Business agility is important here, where new features and new applications can be built quickly. See http://www.jeremychone.com/ for more information about Jeremy and his blog.

Jeremy Grelle of SpringSource talked about the many Spring projects supporting Rich Internet Applications. Spring hopes to augment the popular AJAX and RIA environments like JQuery, YUI, Dojo, and Ext, but also has projects in the works with competing technologies. Jeremy emphasized that balance must be achieved between client side and server side processing.

The balanced approach that Jeremy talked about seems less pure than another theme I saw in several sessions, that RIA should exploit client processing to the greatest extent possible. In particular, Michael Galpin’s presentation on Networked Application Architecture (his blog at http://fupeg.blogspot.com/) noted the migration of RIA processing responsibilities towards the client. Whereas the 2003 view of RIA was that client and server shared presentation logic responsibilities, the preferred architecture is to place all the presentation logic on the client. This exploits the massive increase in client computing power over the last few years, while reducing server burden. We now get this power for free. Michael canvassed some of the most popular RIA environments, like Flex, Google Web Toolkit, Silverlight, and JavaFX. He currently favors the technology of Flex, with its 97% browser penetration, but he sees good improvements in the competition and vendors try to leapfrog one another. Michael also mentioned a couple acronyms to watch out for as emerging impact makers – SOUI (Service Oriented User Interface) and SOFEA (Service Oriented Front End Architecture). I’m working on separate blog article on these, as both use an architecture near and dear to my heart – using services to supply the information to the client application.

Douglas Crockford, most recently famous as the “discoverer of JSON”, gave an interesting presentation on JavaScript (ECMAScript, officially), its strengths and weaknesses. The primary strengths are support of dynamic objects, the lambda property of functions (a function is an object that can be created on the fly, and passed as a parameter), and the loose typing that eliminates casting in most cases. JavaScript does have its shortcomings, but they are not that plentiful. The real problem, Douglas says, is that JavaScript is so easy on the surface, that developers rarely take the time to really learn it in depth. As a result, he calls JavaScript the world’s most misunderstood language, and highly recommends that developers take the time to learn it, as they will be pleasantly surprised. Douglas created a tool, JSLint, a program checker that he feels helps define a “professional subset” of JavaScript that will help developers avoid the few non-obvious pitfalls of the language. For more information about Douglas and his prodigious contributions to the software world, see http://www.crockford.com/.

I also attended a session on Google APIs focusing on RIA support. Google has been a leader in exposing Google features through an API, encouraging early experimentation in visual mashups and client applications. The Google Web Toolkit (GWT) is Google’s development environment for RIA. It is unique in its approach in that a developer writes code in Java, calling APIs as necessary. Then the client application retrieves components in the form of JavaScript, which is actually compiled on the fly from the original Java. A GWT bootstrap module determines the browser type and version, so that the conversion to JavaScript is optimized for that specific environment.

This is just a sampling of the sessions I attended, but does represent the most interesting of the bunch, at least in my mind.

Service Contract Design Strategies

A key design principle for a Service Oriented Architecture (SOA) is the definition of a service contract. The contract clearly specifies the technical interface a client uses to invoke each service operation, as well as the expected behavior of the service. The contract is independent of the underlying implementation, so users of theservice don’t need to care about implementation details and are shielded from its changes over time. Implementers of the service benefit, too, as they have broad flexibility in determining the implementation strategy, and can fine-tune the implementation over time.

When designing data services, there are two main strategies for service design: contract-first service design and data source-first service design. Contract-first design is very much a top-down design strategy, while data source-first design is bottom-up. In contract-first service design, the technical interface is clearly defined first, using XML Schema to define the information flowing across the interface. The information objects defined by the XML schema, which are the primary subjects of these services, are often custom-designed, but sometimes they are drawn from industry standard schemas. If you work within an industry with a commonly used industry XML schema, chances are good that schema contains many definitions you can reuse for your own data services.

Data source-first design often fits the mental model of a data-oriented developer or architect who is intimately familiar with the physical data sources. In this scenario, the emphasis is more on exposing the data as is, combining data from multiple sources as necessary. The design process here follows a trail of building low level components, then selecting a set of them, and combining them together into a composite which is then exposed as a service. The final technical interface is a composite of many lower level components. The contract is simply derived as a result of the composition work. Some caution is warranted with this approach, as the resulting interface is essentially hard-wired into the back-end systems, making interfaces brittle in the face of change to data sources or client needs. The benefit to this approach is that it leads to extremely quick service implementations, and fits the mental model of many of those charged with implementing data services. Areas of development where many fine-grained services are required will benefit from these approaches.

Categories of Services

In previous blogs, I have discussed contract-first service design and the benefits to constructing services as information-rich, smart endpoints. In his most recent book, SOA: Principles of Service Design, Thomas Erl formalizes and extends these ideas by defining 3 categories of services based on the type of logic they encapsulate, the extent of potential reuse, and the degree of focus on a singular domain. The service categories are:

Entity Services – modeled around business entities like customer, purchase order, insurance policy, and invoice. Such a service typically includes the CRUD-like operations to Create, Read, Update, and Delete instances of the business entity. As I’ve mentioned in the past, entity services are ideal candidates for contract-first service design, with entities modeled in XML Schema, and that schema becoming the basis of the interface to create, read, update, or delete a business entity.

Task Services – services that generally model a business process in the enterprise. This type of service very often combines business logic and calls to other services, and because of its focus on a particular business domain, often has a low degree of reusability. Orchestration and choreography environments, along with environments that facilitate flow logic (XAware, for example) are common ways in which to create task services, although many are still writing code to stitch together services with business logic to expose “task” services. Task services also typically involve operations on more than one entity. When processing a purchase order, for example, a process may require validating a customer (using the “customer” entity service), generation of a unique purchase order number (using a order number generator service – a utility service), and adding the order to the provisioning system (using the purchase order entity service). A requirement to access multiple entities is an indicator that your service is a task service. Task services are often referred to by other names, among them: business process services, process services, task-centric business services, or orchestration services (when using orchestration tools).

Utility Services – services that are technology-oriented rather than business focused. Utility services typically provide common and reusable functions that cut across functional domains, such as event logging, notification, and unique number generation. Utility services are often referred to as “technology services” or “infrastructure services”.

The service category definitions are just the beginning in Erl’s book. The heart of the book discusses a palette of principles that guide a designer through the complex activity of creating services with appropriate characteristics for a particular use case and environment within an SOA. This is a book that I highly recommend, and I plan on referencing Erl’s ideas frequently in future blogs.

The Long Tail of Services

The “Long Tail” moniker has been used (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 domain of SOA, business process implementation and integration. If you’re not familiar with the term “long tail”, it 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. The shaded area under the curve can be thought of as revenue. You can imagine that if the tail is long enough, its revenue is significant, and can even exceed that of the head. Chris Anderson coined the term “The Long Tail”, and wrote an excellent book on the subject, which you can read more about here.

The Long Tail

The Long Tail of Services

The long tale metaphor also aptly explains and 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. I’ve ranted in the past that this style of service is not very service oriented.

The Long Tail of Services: Single-use and low reuse services may outnumber those designed for reuse.

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).

Services for Web 2.0 Applications

Building services for consumption in a user-facing application is quite different than building services to feed core business processes. If you download and use any of the AJAX-like environments, or Adobe’s Flex, and build a sample display fed from XML data, you’ll 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. Don’t expect reuse from these, as they were not designed with reuse as a 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. Isn’t 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 by Hay Kranen / PD, and annotated by me.

Web 2.0 Powered by SOA

Mark Scrimshire blogged about attending a Ray Valdes presentation on Portals and Mashups (see the blog here). The article nicely explains how Web 2.0 and SOA technologies combine to produce a new generation of portals, fed by information culled from throughout the enterprise. The separation of concerns between Web 2.0 and SOA technologies can be summarized in a single sentence:

“Information is delivered through a Portal, Not by a Portal.”

Simply put, Web 2.0 provides the visual set of user-customizable portlets, while SOA supplies the information for the visual screens. The information is typically provided in a service-oriented manner, with a lightweight REST approach gaining preference over SOAP for the service delivery mechanism. Interestingly, over 50% of the audience was specifically using an SOA strategy, but only about 10% felt the process was successful. Deployment cylces were reportedly very long, on the order of 2 years before demonstrating value.

The project I lead at XAware.org fits nicely into this Web 2.0 and SOA approach. XAware lets you quickly build and manage data services from any number of enterprise data sources, then deliver those services using a lightweight REST or POX (plain old XML over HTTP) transport. Enterprise data is complex, with the typical company housing hundreds of data sources. The complexity of this environment explains the long development cycles mentioned above. XAware specifically targets the complexity by mapping different sections of your XML-based service contract to different back end systems, using the Eclipse-based design environment. XAware users seem to agree, as the user base is growing rapidly, especially where many data sources and complex information structures are involved.

Eclipse Conned By Microsoft

I attended EclipseCon 2008 this week in Santa Clara, CA. Wednesday's keynote speaker was Sam Ramji from Microsoft, talking about Microsoft's growing participation in Open Source initiatives. He began by confirming rumors that a new initiative, "Supernova", would have Microsoft purchasing the Eclipse organization, and acquiring all intellectual property of Eclipse. A couple weeks shy of April Fools Day, Sam still got lots of laughs on that one, from an understandably skeptical crowd. He talked about his group, the Open Source Software Lab, whose broad purpose it is to assist the open source community with interoperability with Microsoft software. Microsoft recognizes that more and more open source software is running on Microsoft platforms, and they want to continue improving the platform to facilitate this growth. Microsoft sponsors a .NET open source forge at www.codeplex.com. Sam's open source work is closely aligned with Microsoft's recently announced interoperability principles, which signals a more open direction for Office, SQL Server, SharePoint, Vista, and .Net.

While I believe Microsoft is in a different galaxy when gaging their level of Open Source commitment, I do believe they are moving in the right direction. They are doing just about what you might expect from the largest, most successful commercial software company in the world. They are encouraging interoperability to increase their own platform market. But Sam asked for patience from the EclipseCon crowd, noting that in 1995, everybody assumed Microsoft missed the boat on the internet. Ten years later, they are one of the dominant players in that space. Sam propositioned that with Open Source too, Microsoft may be starting slow, but ten years from now, Microsoft may be known as a dominant Open Source player. I am skeptical on this point, as I believe were most of the attendees. But Sam's interoperability initiative is at least a good step in the right direction.

I attended a number of EclipseCon sessions Wednesday morning, covering Service Component Architecture (SCA) tooling, JBoss's jBPM, and Eclipse metadata management initiatives. The SCA tooling is part of the new SOA Tools Platform, one that is emerging as an important member of the Open Source SOA ecosystem. XAware plays well with all these tools, interoperating at a number of levels, ultimately providing information-rich services as the foundation of an SOA initiative.

As if a Microsoft keynote speaker at an Open Source event weren't unusual enough, things grew really strange when I had a brief encounter with a flamboyant Marilyn Monroe while exiting the convention center. A number of her bouncing body parts looked totally fake, not least of which was her platinum blonde hair, obviously a wig. It turns out she was stumping for NetBeans among the Eclipse faithful. For those who don't know, NetBeans is the Sun-sponsored competitor to Eclipse, also an Open Source, pluggable Interactive Development Environment (IDE). Marilyn smiled broadly and handed me a disk, then invited me to the NetBeans party at the Techmart building next door. Instead of heading to my car, I took a left turn towards the Techmart (guess I'm a sucker for such advertising gimmicks), and took a quick walk through. The NetBeans crew had free beer and other refreshments along with demonstrations of the NetBeans environment. I didn't have much time to hang around, but I appreciated the amusing marketing ploy, a perfectly targeted campaign aimed at EclipseCon attendees.

Urban Sprawl in SOA Land

Service development is about to explode in the enterprise, but these are not the custom-crafted, high value, reusable services you might see cruising the pristine avenue of your company’s SOA center of excellence. No, this will be massive. Instead of nicely architected brownstones with clean lines and aesthetic appeal, you’ll brush with small, hastily constructed, one-off services as far as the eye can see. Its urban sprawl in SOA land, and things are about to spiral out of control.

Where will this “urban sprawl” of services come from? The new killer app for SOA is Rich Internet Applications (RIA). Vendors and pundits are vocal about the perfect fit of RIA and SOA. Environments like Flex , Appcelerator, and many of the AJAX-based development environments like Tibco GI seem to perfectly match RIA and services.

It seems like an excellent fit on the surface, using services to populate sections of the display and to perform major operations like "process order". But management of the services is a glaring risk area. SOA generally strives to create coarse-grained services aligned with steps in a business process. You can visualize each service as an activity node on a flow graph. From this basic idea you get many of SOA's benefits: coarse grained, loosely coupled, reusable services that can be re-orchestrated into new business processes.

In the RIA-SOA scenario, left unchecked, I envision a high number of very granular services. Most of these will be tightly coupled, not very reusable, and RPC style. Maybe there is nothing wrong with this, but it is a significant divergence from the core principles of SOA.

I personally like the idea of RIA-SOA, but the trick will be to encourage and enforce SOA principles in the development of this new style of application. Otherwise, expect rampant proliferation of low-value services.

I can envision certain RIA development styles that are more “service oriented” than others. A quick example can illustrate this. Suppose an auto insurance company needs a new policy administration system. From the user perspective, an agent may enter a policy number and expect to see the auto policy in a multiple-tab view. Lets say that one tab shows the policy owner (name, address, contact info, etc), another tab shows coverage information (dollar limits for damage, medical, liability, etc.), and a third tab shows premium information.

The designer of such an application has many alternatives to supply services to power the screens. The primary characteristic differentiating the approaches is how coarse-grained the services are. For illustrative purposes, lets talk about three degrees of coarse-grain-ness: coarse-grained, medium-grained, and fine-grained. A coarse-grained approach would provide services to “get policy” and “update policy”. The RIA application would call “get policy” when the agent enters the policy number. Each tab would read and update appropriate sections of the single, shared policy structure. The agent would click an update button to invoke the “update policy” service under the covers, which sends the policy structure to a service which performs the needed updates. This strategy not only limits round-trip calls to the server, but conforms to SOA norms by encouraging development of more coarse-grained services that are likely more reusable and more loosely coupled.

A medium-grained approach would provide us with a separate service invocation for each of the tabbed panels. Three tabs leads to 6 services to read and update appropriate portions of the policy. The application would likely exhibit better perceived performance, as the user could view the first screen as soon as the first service (get policy owner) completes. While we have potentially 6 round trips instead of 2 in the coarse-grained case, the update operation may deal with less data, since we only have to update individual portions that changed. These services seem reusable and loosely coupled as well, as they are grouped around business information that likely is used by many applications.

A fine-grained approach leads to a larger number of services. Imagine you design your GUI top-down. You go along building screens and stubbing out services you will later create to populate the fields and react to user events. Your services are precisely defined to fit the specific needs of each screen. It a bit harder to imagine this style with our insurance example, but perhaps we define a service to retrieve name, another for address information, and another for contact information. Each section of each screen gets its own service. We have many more services now, but we increase the opportunity for perceived visual refresh performance. Another benefit is that the service definitions fall out immediately from the information sections of each screen, making the design effort straightforward. But the sheer number of services will cost us in terms of management overhead. And these services are so closely aligned to screen layout as to make reuse outside the RIA environment very unlikely.

From this example, we see that as we move down the scale towards more fine-grained services, we increase the opportunity for perceived visual refresh performance while we increase the number of round-trip service invocations to the server. We also increase the management overhead by introducing dramatically more design artifacts.

While the policy administration example shows tradeoffs in the service design approaches, in the context of service orientation, the characteristics are not quite so arbitrary. To be service oriented, you must strive to provide coarse-grained services that are reusable and loosely coupled. To a large extent, if you think in terms of defining the information payloads for services at a higher level, from the business analyst perspective, you will achieve better reuse and loose coupling. On the other hand, if your service interface is defined by a specific set of screen fields, you have tightly coupled your service to its consumer. When the screen changes, your service interface must change. Such a service has a singular purpose, will not be reusable in any other context, and so by definition, is not service oriented.

The message to RIA designers and architects is simple. Yes, industry needs you to combine RIA and SOA to achieve a new level of productivity and richness of user experience. But you should take up of the cause of SOA while you build your RIA. Be service oriented so your services are loosely coupled. Be service oriented so your services can be reused elsewhere. Your efforts will be a productivity multiplier within your organization, bearing fruit from your work long after your current project. Be service oriented, and in the process, you can stop the sprawl.

4 Generations of Services

While working at MCI in 1995, I was exposed for the first time to the benefits of service orientation. I was responsible for the order entry application for 1-800-MUSIC-NOW (which turned out to be a marketing flop), in which call center agents needed to process credit card payments for music CDs. Fortunately for me, MCI was already accepting credit card payment for long distance service. Even more fortunate was that a forward-thinking architect working in the credit-card processing group in Nashville had anticipated future uses of the software his group had developed. What we had feared would require several months of effort turned into about a week of coding to properly access the TCP/IP-based credit card authorization service.

I am sure my experience at MCI is not unique. Across industries, smart architects have been exposing functionality as reusable services. This got me thinking about the how service oriented architectures have been evolving over the years. Those of us working to expand capabilities in SOA tooling have recognized that services and SOA have been around far longer than the "web service standards" that have made SOA so popular over the last few years. It is apparent that in the software industry, we have gone through phases of maturity in our service-oriented implementations.

The long term vision of SOA is to enable rapid assembly of applications by orchestrating services into new business processes. Unlike the modest cost savings I experienced at MCI, the cost reductions achieved in a mature SOA could be immense. The traditional 12 or 18 month development cycles involving armies of analysts and developers are replaced by a business analyst drawing a flow graph of the new process, then clicking a button for deployment to enterprise-ready infrastructure. The "service oriented" approach is measured in days or weeks using a fraction of the engineering resources.

The industry is a long way from realizing the SOA vision, of course, but service orientation has certainly evolved a good deal in the past decade. To better understand this evolution, it is helpful to categorize technologies into generations. For example, programming languages have been categorized as they matured, from machine code to assembly, then FORTRAN, C/C++ and Java, and finally 4GLs like PowerBuilder, SQL, ColdFusion. Each generation achieved higher levels of abstraction and more statement power, making it ever-easier to translate process descriptions and algorithms into machine-executable form.

As service orientation has matured, a number of generations of services have emerged. These generations are defined loosely by how well they support or implement the major characteristics of SOA: standards-based, loosely coupled, coarse-grained, and business-orientation enabling an analyst to understand and manipulate it. Early generations reflect less of these core SOA values, and later generations are more comprehensively based on these values. Looking at the landscape of services over the last 5 years, I see 4 generations of services:

1st Generation Services - Simple services coded in a 3GL language like C, C++, C#, or Java, which don't use modern service standards like WS-* or REST. These services tend to tightly couple the consumer with underlying resources. Older distributed computing technologies like CORBA and DCOM fall into this category as well.

2nd Generation Services - Services that are standards-based and fairly simple, like implementing an operation to retrieve, modify, create, or delete a data set on a database. These services can often be auto-generated from other sources, such as from a Java or C# class, an EJB, or a database query. These services tend to reflect a method on an object, or expose an underlying implementation strategy like a relational table. They are easy to create, but because they are technology-oriented rather than business-oriented, they are unwieldy to use directly in a business process. Instead, they require combining with other services and logic to provide the proper level of granularity for orchestration.

3rd Generation Services - Truly "service-oriented", these services are aligned with a step in the business process. Loose coupling is achieved by explicitly defining data formats that are the payload of the service request and response, and these formats are driven by analysts that know the business process at hand, not by technologists attempting to optimize execution times and storage requirements. These services are often created by stitching together and transforming 1st and 2nd generation services to achieve a coarse-grained service that is suitable for orchestration and at the same time achieves loose coupling.

4th Generation Services - These are 3rd generation services that are institutionalized as managed, secure, governed, and reusable services. 4th generation services involves an ecosystem of SOA-aware technologies and procedures, which allow construction and management of business processes and higher level services. Given time to achieve 4th generation services, a company will maximize the benefits of SOA, enabling them create and modify business processes quickly to meet the changing demands of the business.

The precise boundaries of the generations and the metrics used to categorize a service can certainly be debated. But the concept is valuable in that it helps clarify the goal, to ultimately maximize the benefits of an SOA. These concepts also help justify implementing services in projects that have more modest goals. Maybe you know a function will be re-used across departments. Or, you anticipate that your basic service will be used by a 3rd generation service, thereby growing the foundation that will become an SOA based on 4th generation services. We don't need it all today, but we can derive concrete benefits in the short-term while maneuvering towards an even more attractive set of benefits in the future.

SOA Sweet Spot: Integration

A survey released this week from AmberPoint, titled "State of SOA Adoption Survey", shows steady growth in SOA adoption among respondents. While I always take a vendor-sponsored survey with a grain of salt, AmberPoint seems to have found their way to real SOA implementers in the corporate environment. Systems Integrators, vendors, and consultants were culled out of the distribution list, leaving only end-users: "a database of IT professionals who have an understanding for SOA concepts and methodologies.... a large population of architects, operations staff and developers." Only a fraction of respondents were AmberPoint customers (15%). The promising news from the survey is that the vast majority of respondents (98%) viewed SOA projects as having a high degree of success. That figure breaks down with 38% stating their projects were a success, achieving all desired goals, and 60% cateogorizing projects as "partially successful", meeting most of the goals.

I happen to agree with the results, as they are consistent with a steady growth in SOA projects that I have seen. One of the more compelling survey questions deals with what problems companies are solving with SOA - Integration tops the list by far, with 75% of respondents saying SOA addresses integration-related issues. I saw one article this week about flailing SOA projects (Time for a ’stimulus package’ for SOA? ), but there seems to be a developing consensus that SOA doesn't solve every problem. No surprise there. Like any technology, SOA is good at solving many problems, but some problems are better left to other solutions. What this survey clearly indicates is that integration is SOA's sweet spot.

Junk Yard Parts

Dana Blankenhorn at ZDNet talked today about how the open source ecosystem is a lot like the Pull-a-Part yards in the South and Midwest (see http://blogs.zdnet.com/open-source/). A Pull-a-Part is an auto junk yard that inventories its parts for easy identification and retrieval. I remember my first experience at a junk yard. My dad dragged me along in the hunt for a replacement radio for our Datsun B-210 Hatchback. It was cheap, too: $15 if we used our tools to pull the radio, or $20 if they pulled it out for us. To my surprise, Dad opted for the more expensive package, not wanting to waste his efforts if the radio didn't work.

Dana makes the point that Sourceforge is full of software "parts", and any system you build is made of many parts:

You have to locate them, put them together yourself, and use your own tools. With over 166,000 projects in stock, you're bound to find the one you need.

You can't build today's complex sites and systems from scratch, any more than you can build your own car. But with parts, the right tools, skill, and patience, you can build something very good, very quickly.

And this is why open source is the development platform of choice. Everything you need is visible, right in the yard.

Of course, despite the title of this post, what you get from Sourceforge is not junk. True, many projects are immature, but the leading projects rival the quality and depth of features found in leading commercial products. And if you use the right tools and skills in building your system using quality parts, the results can be excellent.

I would extend Dana's analogy by noting that many leading open source projects go beyond just making parts available, as they provide value-added services and support. Just as Dad didn't want to waste time pulling a part that might not work, as a user, you can pay a small premium for the added assurance that your open source "part" will fit nicely into your project. In addition to free support from the project's community, you can buy support to guarantee answers in a reasonable timeframe, or buy consulting time to help you install the part into your system. Fortunately, there is ample room for both types of users in the open source community: those like Dad willing to pay for a little extra assurance, and those like me willing to pull their own radio (I'm certain now that I would have broken it!). As it turned out, we installed the radio and it worked great. I did my part by handing Dad the tools.

The Un-ESB: Spring Integration

SpringSource recently announced a new project, Spring Integration. See The Server Side at http://www.theserverside.com/news/thread.tss?thread_id=47868 for an active discussion and links to related resources.

Much of the discussion revolves around how the new project works with, or competes against other integration software. I am accustomed to seeing an integration package touted by its marketing department as the new category killer - the best ESB, ETL, EII package available. So it struck me as conspicuous that Mark Fisher, Spring Integration's project lead, failed to categorize the software into one of these well-known (but over-hyped) integration strategies.

From the information I've been able to glean from Mark's blog and the press announcements, the Spring Integration project appears to be a set of tools that let you add ESB-like capabilities to your application. Some of Mark's quotes mimic the value propositions you hear from ESB vendors, for example:

"What this does is it provides a layer of insulation that manages those different endpoints and routes them to the same service implementation..."

It sounds like a service developed using Spring Integration is made available through any number of transports. This is a core ESB feature. So, why wouldn't SpringSource just come out and say that Spring Integration is Spring's implementation of an ESB? After pondering this for a while, I've concluded that its my own biases causing my desire to slap a label on this technology. As project leader for XAware.org, I get questions from analysts and corporate users all the time, asking what category XAware fits into. The analysts like Gartner, Forrester, and IDC educate the masses of corporate management on what technology to buy. A CIO needs to know he's spending 7 figures on the "Best XYZ" on the market. As a software company, you better have a great XYZ to sell to big corporations.

But SpringSource doesn't have to play that game. They're not talking to your CIO. Instead, they are providing technology features directly to implementers. In this case, Mark Fisher and team member Alef Arendsen have both stated that Spring Integration implements integration patterns described by Gregor Hohpe's book, "Enterprise Integration Patterns". You can see many of these patterns at Gregor's site, here:

http://www.enterpriseintegrationpatterns.com/eaipatterns.html

I applaud the SpringSource team for not branding their project an ESB, even though it shares a similar feature set. Though SpringSource has not issued a specific list of patterns supported by the project, I like the direction they are heading. The integration market is fragmented and full of marketing hype. By pointing to well-defined integration patterns, SpringSource strips the marketing glaze and displays a transparency that is very refreshing.

Extreme Governance?

There was a lot of talk about governance this week at Gartner's Application Architecture, Development & Integration Summit in Las Vegas. What is SOA governance? Simply put, SOA governance defines the policies, procedures and rules of how an organization implements and manages its SOA. Just like we have a development process guiding how we develop core software (XAware uses Agile/Scrum), SOA governance defines the process for SOA development initiatives across the enterprise. Issues to be managed include who can define services, who implements services, permissions for who can access them, on what platform they run, and who pays for development and maintenance.

At the show, I talked with many enterprise users to get reactions to the governance talks. The message from Gartner is clear - Paulo Malinverno stated in one presentation that an SOA with no governance is doomed to failure. But most of the companies I talked to, in trying to implement SOA, are either not implementing governance, or are still struggling with how to do it. I am convinced many others have governance, but are calling it by a different name. The common strategy seems to have a single point of authority, such as an enterprise architecture group, which defines the policies and ensures compliance.

In a conversation with Gartner analyst Roy Shulte, I asked his thoughts on SOA governance. In his view, governance is merely "the workflow in IT". Again, this sounds like nothing more than a process to manage services and other components in the SOA.

Just Enough Governance

Paolo and others caution against too much governance, which might smother and cripple a fledgling SOA initiative. In this respect, I look at agile development processes as the model for appropriate levels of controls. Scrum and XP both value working software over documentation and heavy-handed processes. In fact, I like the term "extreme governance" as a moniker for SOA governance in an agile environment. For developers, the connotation is light-weight, as-needed controls. For the executive who skims over details, the company's "extreme governance" process should win bragging rights in the fight to maintain firm control over the IT rebels. We'll fill him in on the play on words later.

For my part, I would simply recommend to users to stay pragmatic. Services are becoming easy to build, so the number within the enterprise will naturally grow rapidly. The key is understanding that some of the services should become "investment engines" that deserve more oversight to extract meaningful, enterprise-wide value. Services on the edge of an enterprise require more control than services deployed for departmental use. Services with broad use potential within the enterprise should be institutionalized and deployed on enterprise-scale, operationally sound infrastructure. To me, staying pragmatic and applying controls in the proper contexts is the definition of "extreme governance".