SOA and its Relevance to ISVs

| | Comments (0) | TrackBacks (0)

Ronald Schmelzer posted a fantastic article on ZapThink about the relevance of SOA to Independent Software Vendors (ISVs). In it he says that the reasons that ISVs should build their application in a service-oriented fashion are the same as for large enterprises instigating company-wide service-oriented initiatives. Specifically, he states that ISVs should design their applications using service-oriented practices, so that their customers can:

  • Reduce their integration expenses,
  • Achieve a faster time-to-market,
  • Lower their total cost of ownership (by reducing the need to hire system integrators and/or consultants), and
  • Increase business agility.

Some of these benefits are also experienced by the ISV themselves when they use this architectural paradigm. For instance, by reducing coupling within an application, an ISV can more easily alter its product to meet changing customer demands. Schmelzer warns that it isn't enough to slap some Web services around a monolithic application and plaster "SOA" all over the press release, however. I appreciated this admonishment because of the common misconception in our industry that Web services and SOA are the same thing.

Having read this article, however, I'm left wondering what aspects of an SOA should an ISV's offerings include? There are many facets to an SOA. Which ones should be included with a service-oriented product? Of course the answer is that it depends and that there isn't any hard and fast answer; however, it is helpful to enumerate the common characteristics on an SOA and think about:

  • Which traits are pertinent to service-oriented products built by ISVs,
  • Which qualities could be included, and
  • Which ones should be left solely to the end customer?

To aid in this discussion, I'll use Thomson Erl's fantastic book Service-Oriented Architecture, Concepts Technology, and Design as a reference for what characteristics SOAs commonly have. The following table shows the characteristics sited in Erl's book and which ones must, may, and must not be exhibited by service-oriented products sold by ISVs.

Common Characteristics of an SOA

Must

May

Must Not

Based on Web services

X

QoS-capable

X

Autonomous

X

Open

X

Vendor-neutral

X

Discoverable

X

Interoperable

X

Federated

X

Composible

X

Reusable

X

Extensible

X

Encapsulate business logic

X

Abstract

X

Cohesive

X

Promotes organizational agility

X

Elemental

X

Evolvable

X


Some of these terms may be unclear and others deserve special note, so I'll elaborate. For a more thorough explanation, please refer to Erl's book.

Based on Web Services

Any product that an ISV creates cannot be integrated into an end customer's larger SOA directly unless it is built using Web services. This implementation technology will allow an ISV's product to be incorporated and controlled by outside forces within the end customer's service-oriented enterprise (SOE). This will lower their TCO as mentioned above, thus winning ISVs deals that their competitors will lose due to higher integration costs.

QoS-capable

In order for the offerings of ISVs to be incorporated successfully into a larger service-oriented solution, they must insure that:

  • Tasks are carried out in a secure manner, information is exchanged and stored in a protected form, and service access is limited to authenticated and authorized callers;
  • Operations are executed in a consistent fashion, messages are delivered reliably, and reports of failures are guaranteed; and
  • Operations are transactional and can be rolled back in case of errors.

Open, Vendor-neutral, and Interoperable

Services within an SOA should be compatible with open specifications that are governed by international standards bodies; however, this requirement isn't always necessary, pragmatic, or performant. In my opinion, the level of openness required of a service is directly related to its proximity to others that are built on a different platform. A service that is used in a homogenous environment, need not concern itself (as much) with interoperability. In such scenarios, services can use proprietary extensions and other optimization. If the services sold by an ISV will not be exposed by their customers but will be used as building blocks in their larger SOA, they may use non-standard protocols where it makes a difference in terms of performance, reliability, and security. Similarly, an ISV's system need not be vendor-neutral if the target market accepts the bias. When purchasing a vendor-specific, service-oriented product from an ISV, the end customer should encapsulate the proprietary aspects of the underlying services. By doing so, the final SOA will be vendor-agnostic. If a customer doesn't do this, their service-oriented initiative will likely degrade into a "wild west SOA frontier". To avoid this, companies that purchase service-oriented systems from ISVs should police them with SOA governance products like those from SOA Software and AmberPoint.

Discoverable

This characteristic is an important one that most ISV-produced offerings probably don't exhibit. To be discoverable, a service must publish its endpoint in a way that allows service consumers to find them dynamically at runtime without human intervention. This publication process is typically done in an SOA by pushing information into a central registry using UDDI. When discovering services that have been published into a UDDI registry, consumers must specify search terms that describe the capabilities or characteristics of the services that can fulfill their task. These descriptive terms are associated with services when they are published into the UDDI registry. Obviously, the terms/metadata must be shared by services published to the UDDI registry and customers needing their functionality. What this means is that:

  1. ISVs will have to create their own metadata taxonomies to describe their services or
  2. Use existing taxonomies (e.g., Dublin core).

If an ISV doesn't use a standard nomenclature or go through the trouble of creating one, their customers won't be able find and dynamically bind to their services at runtime. The creation of these taxonomies is a costly and time consuming task that is difficult to do in a way that will fit the ISV's eventual customer's needs. If this difficulty, however, prevents such a classification from being created, integration will be inhibited, decreasing the value of the ISV's product.

Federated

Erl says that an SOA should promote federation by unifying environments that were previously disconnected due to the architectural limitations of those systems. This characteristic is not one that ISVs should try to provide (on a sweeping, enterprise-wide scale at least). You can't buy SOA in a box as Schmelzer points out in the blog entry sited above. That said, by being service-oriented, an ISV's offering will be more easily federated into the consumer's SOA, which is the entire point.

Composible

The services that make up an ISV's product should be composible. If an ISV wants to provide their customers with increased business agility, they will need to compose the ISV's services together in ways unoriginally expected. This can be inhibited by a lack of interoperability, nonconformance to standards, and vendor-bias. If composition is precluded by these qualities, then the service implementation should be reevaluated or else an ISV's offering will be overlooked for others that are composible.

Encapsulates Business Logic

Service-oriented systems built by ISVs should be autonomous. This means that the services that comprise them should all be independently versioned, deployed, operated, and secured. This tenet of SOA insures that the end result is agile and able to move with changing business demands.