Introduction

One of the stated advantages of Service-Oriented Architecture is the ability to get away from "silo" thinking within IT, the development of applications as islands of functionality. We tend to think of applications today as a vertical integration of a set of components built for this one purpose. It is often the case that development projects are set up around the development of, or maintenance of, an application and in some extreme cases development teams are solely responsible for a single application. The following picture represents a common business application structure, showing that really the only reuse between applications is often that they share a common database.

Whereas the Service-Oriented approach would lead us to a more horizontal view of applications as an integration of services; so in fact all of our services are peers in a portfolio of capabilities from which applications, which can now be thought of as those parts of the IT solutions interacting with users, can be developed. The following demonstrates how the Ordering application can be developed as a set of user-facing portlets for integration into a portal server, and that the business logic is provided by a set of services which in turn utilize a set of infrastructure services.

Services provide independently deployed components that are provided at a granularity that typically allows them to be entirely self-contained, this leads to services that manage and protect their own data stores rather than sharing database storage. This seems to be in contrast to moves by some companies over the years to introduce common data stores, or at least common data models that all applications share. On the contrary a service-oriented architecture tends to lead designers into developing not common data storage models but common message models to ease the integration of services through middleware technologies.

Enterprise View 

As we mentioned before both projects and development teams have a limited scope and also a limited visibility into the wider capabilities, requirements and goals of the IT services and more importantly the business the services support. It is therefore critical that, during the move toward Service-Oriented Solutions and the horizontal view of integrated solutions, the architects on the IT side are able to visualize the portfolio of services supporting the business solutions required for the business itself to operate. One advantage to modeling services is that an abstract model is able to elide certain details and therefore present the broad view of the service portfolio in a scalable manner, i.e. in the presence of many services the model is able to present views of the portfolio supporting decision making for the Software Architect and Designer.

Obviously as organizations transition to Service-Oriented Architecture there will be a growth in services and so the portfolio will not start as a large model, but it is possible to capture the state of the transition in terms of available as well as planned services. Service Partitioning is also vital in organizing the model and categorizing services as the portfolio is developed.

Categorization of Services 

During early stages of service identification (see Activity: Existing Asset Analysis) it is common for candidate services to be captured as simply a list of names, possibly structured as a hierarchical list or stored in a spreadsheet. Such a list is useful when working in a workshop environment and eliciting candidate services from source material. As the number of candidate services increases, an unstructured list can quickly become unmanageable. Therefore, as soon as possible a service categorization scheme should be identified so that candidate services can be organized into groups within the category hierarchy.

While a simple list of service names can be a quick starting point, it will eventually be important to capture additional information about each service. This information can be subdivided into two types: information that supports service identification, and information that supports service specification. Service identification is focused on building a portfolio of services that can be associated with business functions, business goals, assets such as existing systems, and an indication of whether the service is considered a candidate service, or has been chosen for exposure.The service portfolio template can be used to document services at the level of detail needed in the service portfolio.

It is important to be able to categorize the services in the portfolio in a number of ways, but most commonly we use terminology that describes the service's purpose, ownership or organization. To support this categorization or classification each Service Partition has a Classification property that can be used to denote the classification kind, the name of the partition becomes a value in that classification scheme.

For example, the following diagram (or some variant) has been developed by a number of companies to help visualize the "types" of services in the portfolio.Note that this categorization, while common, is simply one possible way to segment the service portfolio. In this example each partition is named with its classification property set to "zone".

• User Interaction Services are used to describe how the user interacts with the application; for example, for a service that may need to assign work to a human user there needs to be services that know how to notify the user of this work and then notify the originating service of the work completion.
• Application-Specific Services are services that are developed as a part of a development activity that have been deemed as not appropriate for reuse and so are not considered a part of the portfolio. It is also possible that, as services are composable entities, that a service may be part of the portfolio yet nested services it uses are not published.
• Process Integration Services are services, usually provided by commercial middleware, that provide the choreography of services so that processes can be enacted in the middleware and utilize the services in the portfolio to implement a process.
• Information Integration Services are again commercial middleware services that provide services for the mediation of data formats and message content between services; for example a customer message can be generated by the service which is an aggregation of data retrieved from other services in the portfolio.
• Business Services are those services specific to the business, developed for the business and providing direct support to the applications developed to support the business. Examples might be CustomerMgmt, Inventory, HR, etc.
• Infrastructure Services are services that provide common IT functions required not only by the Business Services but by the integration services as well. Examples might be Messaging, Directory, Authentication, Legacy access, etc.

For more examples of classification kinds see the concept Service Partitioning.

Service Repositories 

So, apart from a model of the service portfolio it is important that Designers and Developers have access to service specifications in a detailed fashion at design and implementation. It is also possible for multiple services to implement the same specification and so a registry allowing queries of the form "all services implementing the IOrdering specification" allows for developers to compose solutions from existing services, and integration developers to identify which services to use to satisfy business or technical requirements.

Service repositories are also able to use the classification values introduced using the service partitions above to pre-populate the values as metadata describing the services held by the repository.

For example, a solution may call for a shipping service, the registry may identify 3 services that provide shipping, two provide secure message exchange but one only does so over Java Message Service (JMS) while the other provides SOAP over HTTP. Business requirements only specify that customer information be kept private and so a secure message exchange is required, IT standards recommend that JMS not be used to a remote service and so we have narrowed down our choice.

The following presents some of the technical implementations available currently for service registries.

• UDDI; The web services standard registry, this has wide adoption and was intended to support both development and integration time queries. However, the level of customization required to keep track of all of the data associated with a service specification has certainly led to some questions about whether UDDI as it stands today is enough to support the enterprise service portfolio we discuss here.
• RAS Repository; The Reusable Asset Specification was intended to support a customizable metadata description for reusable assets, and does have a metadata profile for web services. While it was not the intent for RAS to provide a service portfolio it would be possible to do so for development time metadata although it is not currently appropriate for integration time queries.
• Custom; Many organizations, faced with these choices, have chosen to implement custom service repositories, managing a set of metadata or design documents for services at design time and associated web service artifacts for implementation time. In most cases a separate UDDI repository is then used when deploying production services for integration time queries.