Recently in SOA Category

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.

Enterprise UDDI Services in Windows 2003 has many attractive benefits.  Here is a shortlist of some of those advantages:

  1. It’s free and is available with every edition of Windows Server including standard!
  2. Compatible with the UDDI v. 2 specification that’s governed by OASIS.
  3. Built in support for storing data in SQL Server.
  4. Convenient .NET-based SDK that simplifies working with the UDDI by alleviating the client programmer from having to use SOAP or Web services.
  5. Ability to publish the location of the UDDI registry in Active Directory, so that clients can find it automatically without having to rely upon configuration.
  6. Management is done through a Microsoft Management Console (MMC) snap-in that provides a common appearance and user experience that IT administrators are used to.
  7. Web-based UI for managing, viewing, and searching the UDDI registry.
  8. Integrated Windows authentication that can use Active Directory accounts or local server accounts.
  9. Authentication is support via tokens as defined in the UDDI v. 2 specification.  Tokens are mapped to Windows accounts that can be managed centrally by IT (in the case of Active Directory) or local server accounts can be used.
  10. Authorization and permissions are based on roles/groups (local or central).
  11. Built-in logging that is written to the Windows event log.
  12. Pre-made GUI tool that can be used to define and export custom taxonomies which can be imported into a registry to aid in the discovery process (available in Windows 2003 Server Resource Kit).
  13. Included wizard for registering WSDL documents in UDDI registry (helpful in pushing a services description to a development registry prior to deployment).
  14. Resource Kit includes command-line tools for importing and exporting server configuration settings.
  15. Provides extensions to the UDDI standard that allow for the creation of hierarchical taxonomies.

Given all this, what are the drawbacks?  What are the benefits of other products from alternate vendors?  What's changing in Windows Server 2008?  Are there any plans to upgrade the service to v. 3 of the UDDI specification? 

All of these are important questions when deciding whether or not to standardize on Microsoft's offering.  Though I don't have the answers to these questions, hopefully, the above list will help you in your decision making process.  If you have the answers to the questions, or any thoughts, please leave a comment.

In order to communicate effectively about a service-oriented system, stakeholders must use a shared nomenclature when discussing the different types of services within it.  Their seems to be a real need for such a taxonomy in our industry, so I would like to share the following terms in hopes that readers will offer suggestions and additions.  To help understand all of these classifications, the following Venn diagram shows the relationship between the different service types.

 

 

Utility Service

The utility service is a class of services that is comprised of those that are small, compact, indivisible and are used as the building blocks in a service-oriented system.  They are used to construct the larger, higher-level services.  They are not cluttered up with product- or system-specific logic or functionality (which instead is found in controller services).  Utility services are atomic.  Their standalone nature insures that the system is agile and flexible from the ground up.  Their unfettered construction allows these core services to be easily reused across may service-oriented applications; it also facilitates swapping them out without causing system-wide disruptions.  Entity, proxy, and framework services are examples of utility services. 

Proxy Service

The proxy service classification is comprised of those services that function as a bridge between other members of the service-oriented system and incompatible subsystems.  Device and process services fall into this grouping.  Services in this class are sometimes referred to as wrapper, broker, or gateway services.  Proxy services are analogous to the design pattern by the same name popularized by the GoF. 

Device Service

Device services are a specialized type of proxy service that stands in front of a hardware device.  They are used to control and communicate with devices that do not natively provide an API that is compatible with the protocols used throughout the service-oriented system.  A device service translates between the machine’s communication channel(s) and those required to converse over the service bus. 

Process Service

Process services are another type of proxy service that are similar to device services.  Unlike the latter, however, the former is used as a translator between a software application and the other members of the service-oriented system.  Process services are almost always required to bring legacy software onto the bus.  

Controller Service (aka Business Service)

Services that fall into this category are those that orchestrate the smaller building block services together to solve certain business requirements.  These services must be as flexible as possible to meet constantly changing business needs.  Often, these services are built using workflow technologies, allowing them to be implemented using a graphical, drag and drop programming model.  This implantation strategy insures that they are produced quickly, keeping their development cost low.  The TCO and rapid development of these services is important because they are highly susceptible to change and are the most product-specific services within a service-oriented system.  Controller services manage utility services. 

Entity Service (aka Data Service)

Entity services expose a single concept that is physically stored within a database.  They are uncluttered by other utility services such as notifications and auditing.  They provide access to information stored in backend databases via communication protocols used on the service bus rather than any technology-specific data access mechanisms such as OLEDB, JDBC, etc.  They also shield consumers from any particular database server or specific database server version, isolating the system from changes in the IT infrastructure. 

Framework Service

Framework services are those necessary for every SOA.  Regardless of the industry or product, all service-oriented system have them.  They may not all have device or entity services, for example, but every SOA will have framework services.  Examples of services that fall into this category include logging, auditing, notification, and security services. 

Integration Services

Integration services are those that lie at the perimeter of a system.  They play a similar role as process services; however, they are distinct because of their outlying position.  Together with controller services, integration services stand at the outer-most edges of a service-oriented solution whereas process services incorporate incompatible software applications into the system.  Process services hide incompatibilities; integration services provide the input paths to the SOA.  They do this by supporting many different communication protocols through which they receive messages that are normalized before being relayed to other service connected to the bus.   Integration services are often implemented using EDI products such as BizTalk. Though controller services also stand at the borders of an SOA, they do not support a wide array of input channels through which messages can flow as integration services do.

Service Oriented Architectures are built upon four tenets:

  1. Service boundaries are explicit
  2. Services are autonomous
  3. Services share contracts not code
  4. Services are compatible based on policy

When building services, it’s important to remember that these are tenets, not laws. This is important because service-oriented systems are built differently depending on their size. Michele Leroux Bustamante underscored this distinction earlier this week at Dev Connections by using the terminology “big SOA” and “little SOA”. When building little SOAs, it is difficult and some times impractical to adhere to the above guidelines. For example, in the figure below, service one and two are crossing the boundaries by accessing the same data store. While this may clash with the first SOA tenant, that’s OK.



In the case of little SOA, dogmatic conformance to the tenets could incur performance, maintenance, and other such cost that will inhibit its success. Big SOA is the orchestration and composition of multiple little SOAs. If unquestioned devotion to the tenets of SOA impede the construction of the little SOA building blocks, there can be no enterprise-level service-based architecture.

The construction of these different sized services vary in other ways as well. For example, a big SOA is often built from many smaller, entity services. An entity service is one that provides basic CRUD for database entities. These services often provide dozens of different operations to perform this type of basic functionality; however, they aren’t limit to simple CRUD functionality and commonly include other operations that are still relatively low-level. For example, one may create an asset service which exposes basic asset-related CRUD functionality in addition to other capabilities such as grouping and relating assets. Regardless, all of these operations end up altering database records.

When building this type of service compared to one that makes up part of a big SOA, it is impractical and unnecessary to adopt the recommended practice of explicitly defining the message contracts of the entity services. If this guideline is adapted, the entity service will require two message contracts for each operation, resulting in an overwhelming number. Furthermore, these messages of such services often contain nothing more than a data contract, resulting in a senseless wrapper. Though Juval Löwy advices in his book Programming WCF Services that service contracts should expose only a handful of operations (with a suggested upper limit of 20), little SOA building blocks like entity services usually can’t follow this recommendation.

On the other hand, when building the services of a big SOA that cross organizational boundaries, small, specialized, highly-interoperable services are paramount. To achieve this, the definition of message contracts is a must. Unlike little entity services, however, these wide-reaching services often expose very few operations and only a handful of message contracts. This is very manageable and merits the cost of defining, versioning, and maintaining the extra message-level contracts.

The point is this: architects can’t be unquestionably apply the tenets of SOA in a back-or-which fashion. We have to open-mindedly question and think critically about our problems and the established service-oriented guidelines for building loosely coupled architectures.

Loose Coupling

| | Comments (0) | TrackBacks (0)

Juval Löwy describes the four tenets of service-oriented architectures in his wonderful book Programming WCF Services

  1. Service boundaries are explicit
  2. Services are autonomous
  3. Services share operational contracts and data schema, not type-and technology-specific metadata
  4. Services are compatible based on policy

By building upon these pillars, engineers insure that the architectures that they define are service-oriented.  These guidelines help insure that the components within a system are loosely coupled – a key requirements of a SOA

The importance of reduced coupling isn’t new or SOA-specific.  I remember being taught in college to strive to lower coupling irrespective of the architectural pattern being applied; however, I don’t recall being given any practical advice on how to achieve this or any metrics to measure it. 

In fact, I’ve heard it said that coupling can’t be quantified; I disagree, however.  If you count the number of distinct service operations which a client invokes, you can determine how tightly it’s bound to that service.  Swapping it out would require a new one to supports at least the same functionality.  If you don’t own all of the clients, you can’t make this determination, however, and must assume that all of the operations are in use. 

For this reason, it is advisable to:

  1. limit the number of operations exposed by a service (Löwy suggests no more than 20);
  2. not define two methods if one will suffice (i.e., avoid convenience functions); and
  3. if the arguments of an operation are likely to change and are numerous, bundle them together in a structure and pass this to the operation.

For other pointers, see John Evdemon’s blog as well as David Orchard’s.  After reading those, check out the other suggestions that Löwy has in Appendix C of his book Programming WCF Services.  I also suggest browsing through Milind Shingade's article where he defines different types of coupling.