ervice-oriented architecture (SOA) is rapidly becoming popular as an approach for developing business applications that more effectively produce business value. Organizations adopting SOA often find that the most difficult part is simply getting started. In this excerpt from Exploring IBM SOA Technology & Practice, Bobby Woolf introduces IBM’s SOA Entry Points, a simple but effective vendor-neutral approach for discovering and developing services a few at a time. With this process, an organization can get started with SOA easily, and quickly be on its way to SOA success.

Reproduced from the new book, Exploring IBM SOA Technology & Practice, authored by Bobby Woolf, by permission of Maximum Press. ISBN 978-0-9773569-4-2. Copyright 2008 by Maximum Press. All rights reserved. For more information please visit: www.maxpress.com.

Introduction
The IBM SOA Entry Points are five specific approaches for getting started with SOA. They enable an organization to get started discovering and developing services a few at a time. They are distinct and consumable starting points requiring a limited set of products and skills to get started.

Three of the SOA entry points are business-centric, applying directly to the tasks businesses perform to produce value for customers. These business-centric entry points are:

• People ? Productivity though people collaboration
• Process ? Business process management for continuous innovation
• Information ? Delivering information as a service

The remaining two SOA entry points are IT-centric. They are not as immediately recognizable by business people, but they help to integrate and reuse the business-centric SOA services. They are also technology-focused approaches IT can use to get started with SOA. These IT-centric entry points are:

• Reuse ? Creating reusable functionality
• Connectivity ? Underlying connectivity to support business-centric SOA

The entry points are distinct but can be used in combination. They are techniques to use to discover what services are needed and to develop those services. They’re ways to look at the requirements for applications and business capabilities and figure out what services are needed.

Let’s explore the entry points in detail.

People
The people entry point focuses on services that enable human users?employees, partners, and customers?to be more productive and to collaborate more effectively. Such services can aggregate information from otherwise unrelated sources based on each user’s specific context. They can interact with business processes to enable humans to participate in otherwise automated and centrally managed processes. These user-oriented services hide the boundaries created by separate applications and data centers, presenting a unified experience that is exactly what the user needs.

People-focused services can be implemented using any technology for user interface components, typically a graphical user interface (GUI). GUIs today are often Web interfaces created from dynamically generated HTML, produced by technologies like JavaServer Pages (JSP), portlets, and Asynchronous JavaScript and XML (AJAX). A JSP can accept input used to invoke a service and can display the service’s output. A portlet is a reusable GUI segment, designed to be composed with others in a single portal screen. A service portlet accesses its data from a service and then displays it in the portal; the configuration of the portlet often acts as input to the service. New portal screens can easily be built by combining together existing portlets, each of which just needs its corresponding service to be available at runtime. Likewise, people-focused services can be used to support Web 2.0 GUIs, such as the AJAX technique for interactive Web GUIs, which retrieves new data for a display by asynchronously invoking a service. People-focused services can also be used to develop alternative user I/O, such as GUIs for the limited screens on mobile devices and audio I/O for telephone access.

The value of people-focused services is that they enable users to exploit services and even act as services, and to experience the benefits of SOA directly. Composite applications, especially those with portal and/or Web 2.0 GUIs, can be created, deployed, and updated easier, faster, and more reliably using SOA techniques.

People-focused services fit well into SOA because they enable the user interface to be composed of services. A composite application can be custom-composed of reusable services, and then its UI can likewise be custom-created using widgets that already know how to display and interact with those services. Because this unified model is a set of services, it can be reused for different types of users, creating consistency of user experience and eliminating redundant efforts to implement these experiences.

There are a couple of good ways to get started developing people services. Look for business tasks people perform that require them to access several separate applications. Also look for tasks requiring lots of different information, or tasks where the information needed differs for different types of users in different contexts. Services like these can be extended to create alert-driven dashboards that let people know when there is work to be performed.

Process
The process entry point focuses on services that enable businesses to automate their business processes?a predictable chain of tasks that produces a business result. An organization uses this entry point to build business processes from reusable components, optimize them, and then can easily update them and monitor their execution.

Process services are often implemented using business process execution language (BPEL), an XML document schema for describing business processes. Systems analysts and developers use business process editors to develop business processes, whose output is BPEL. Administrators then deploy the BPEL into a business process engine that executes the business process at runtime. The current BPEL standard does not support human interaction, and so is often supplemented with other emerging standards like WS-BPEL Extension for People.

A value of process-focused services is that they enable systems analysts to quickly and easily describe what a business should do without initially getting bogged down in the details of how it should do it. For example, processing an insurance claim can look as simple as: gather details, verify details, adjust claim, and issue payment. Those steps can be implemented separately; the way a particular step works may be completely redesigned, but the overall process remains valid. The process is not lost in the code, but is externalized where it can easily be understood, measured, and adjusted.

Process services fit well into SOA because the process itself is a service and each activity in the process is a service. New services can be created easily by developing new processes that combine existing services together in new ways. Business processes lend themselves to monitoring, with their status displayed in dashboards.

To start developing a process service, look for a business process that needs better automation or monitoring. Such processes often run as batches in the background: A customer submits an order. A policy holder submits a claim. A business partner makes a change affecting several systems. A business process can start immediately, and automatically creates a history of how many are running and what they’re doing. The services used to develop a business process can then be reused in different compositions to develop other business processes.

Information
The information entry point focuses on services that enable all applications to access and update the same consistent view of data, as if the entire enterprise contained just a single database. Traditionally, each application implements its own data access to what is supposed to be the same data. Data spread across multiple databases and inconsistencies in data access can lead to different applications answering the same query differently, causing inconsistent user experiences. Likewise, the same information must sometimes be stored in multiple databases, which means that each application that updates the data must update all of the databases consistently. When the data is moved or the format must be changed, each application using the data must be independently updated, which can cause more inconsistencies.

Information services can best be implemented using a data integrator that acts like a database with a services interface but is capable of performing extensive processing on the data. The simplest services provide reusable access to CRUD?create, read, update, and delete?the data, both structured and unstructured. More powerful services integrate information that resides in a range of heterogeneous repositories, possibly with redundant and inconsistent information?data that may need to be cleansed, consolidated, and/or enriched. Services also simplify access to external sources of data, such as querying a business partner’s inventory.

The value of information-focused services is that they hide the details of how the data is accessed. As new sources are added, old ones removed, and data rearranged, only the service implementations need to be updated; the applications using the services remain unaffected.

Information services fit well into SOA because they enable an SOA application to treat information as a service. Services typically perform business functionality, but sometimes that functionality is essentially to CRUD some data. A business process to fulfill a purchase order may need to access a customer’s credit profile; that access can be a service that simply retrieves the profile data. That profile data may be scattered among different databases needing integration, and may need enrichment and cleansing. Those databases may be different tomorrow than they are today; in all cases, the service hides those details. The process may also need to update the purchase order. It can do so using a service that hides what databases and schemas are actually used to store the order.

To start developing an information service, look for data that needs to be accessed?read and/or written?by a variety of applications, especially data that needs to be made available to business partners in a controlled fashion. A key example would be access to databases of record for master data elements. This approach is especially helpful when the applications do not agree entirely on the data format to be used, when the data is partitioned or duplicated across multiple databases, or when the data needs to be cleansed. The service provides a single point of access for all applications that need to read and/or write the data. Information services then lead themselves to monitoring to determine if and when specific data is being used.

Reuse
The reuse entry point focuses on services that enable applications to share functionality. A reusable service provides reuse not just at development time, through shared code, but at runtime, through a shared execution environment. It is an especially good approach to access existing functionality in so-called legacy systems. A reusable service may or may not map nicely to an easily recognized business task; it may be an IT service that nicely encapsulates behavior that several applications need.

Reusable services can be implemented from scratch or can wrap existing functionality. When creating a brand new component, it can be made more reusable by making it a service?giving it a context-free API and an interface based on open standards, and deploying it such that multiple applications can link to it at deployment-time or runtime. A service may simply wrap functionality that already exists, yet the wrapping still provides value by making the functionality far easier to reuse by a variety of applications, even if they’re written in different languages and run on different platforms. A legacy application written in COBOL running on MVS with a copybook interface may be difficult to reuse; but create an adapter for it with a WSDL interface and XSD data structures, and then any Web services client can use it.

The value of reuse-based services has several aspects: Reusable functionality shortens development time by reducing redundant design and development effort and leveraging assets that have already been tested and debugged. By deploying the functionality as a service, it is instantly available to any application that can connect to it. Because it is not embedded in all of those applications, bug fixes and feature enhancements are easier and less disruptive to deploy. Systems encapsulated behind a service interface are easier to later replace or outsource; they’re also easier to make available to business partners.

Reusable services fit well into SOA because one of the main goals of SOA is reuse. When two business processes can use the same activity, that’s reuse. When two applications need access to the same data, that’s reuse. Even when the business people have difficulty identifying reusable business tasks, IT people can usually identify reusable components. Making the reusable components into reusable services makes them part of an SOA.

To start developing a reusable service, look for opportunities for reuse. When multiple applications need the same functionality, make that into a component; and rather than deploying that component embedded in the applications, consider deploying it standalone as a service that the applications link to. When accessing a legacy system, strive to wrap the access code in a service interface that’s deployed with the legacy system; then it can be reused by other applications that need to access the legacy system, without each of them having to implement their own access.

Connectivity
The connectivity entry point focuses on providing access to services?regardless of the location of the consumer or provider?via open standards and, when needed, proprietary interfaces. Even when a service is available for reuse, finding it and a way to connect to it can be half the battle. Even if the interfaces match, remote access across networks can be notoriously unreliable. Even with matching interfaces over reliable networks, a service consumer actually needs access to multiple providers of a service, making the service itself reliable and scalable. Even when a consumer knows how to find a provider, the provider may move, in which case the consumer has to be able to find it again.

Service connectivity is best implemented by an enterprise service bus (ESB) and service registry. An ESB acts like a provider to service consumers and a consumer to service providers. It acts as a single connection point to a consumer, but can connect to multiple providers and route different invocations to different providers. When the consumers and providers don’t match, the ESB can perform mediations to bridge the differences. The difference might be in data format bridged by a transformation, transport bridged by a conversion, or purpose bridged by a routing. In the process, the ESB can provide and enforce security and act as a point for management and monitoring?not just of the services or even their individual providers, but at an even more fine-grained level, the individual invocations of the services. Meanwhile, the registry keeps track of the available providers of each service, metadata about the providers, and their current status. The ESB can use the registry to find providers when it needs them.

The value of service connectivity is that a service that cannot be accessed cannot be used. The more complex service access becomes, the more difficult an SOA is to develop and make operate correctly. Service connectivity encapsulates the access, making the means of access reusable, as well as simplifying both the consumers and the providers. It creates a place to implement mediations so that consumers and providers that don’t match can still work together. By necessity, service consumers and providers will tend to evolve somewhat independently; as they do, mediations will help bridge the differences.

Service connectivity fits well into SOA because developing service consumers and providers is only half the battle; they need to be connected as well. If every consumer matched its provider and they evolved in lockstep, each consumer had only one provider, the providers’ locations and status never changed, and the consumer and provider ran in the same process or at least on the same machine, then service connectivity would be much simpler. But the promise of SOA is that it will work even when interfaces don’t match, will enable each consumer to transparently access multiple providers that are not always available, to access them remotely across networks that aren’t always reliable, and will enable providers to change their address, old providers to go offline, and new ones to come online. Service connectivity makes this possible; it decouples the consumer from the provider.

To start developing service connectivity, look for services (that is, service providers) that could be reused more if only they were more accessible. Perhaps multiple Java applications running on UNIX servers are having trouble accessing a service hosted on a mainframe, especially because they can become overloaded or sometimes get taken offline. Perhaps a business partner needs controlled, secure access to a service. Maybe a composite application has consumers running in one data center and providers running in a different data center. Perhaps the binding for accessing a needed service changes from time to time. Service connectivity makes services easier to reuse in general, but especially in these more extreme circumstances.

Conclusion
As we have seen, the IBM SOA Entry Points provide five specific approaches for getting started with SOA. They enable an organization to adopt SOA by building and using services a few at a time, without requiring a significant investment in skills or products. They can help you quickly and easily start down the path towards SOA success.