Emerging infrastructure components for Web services and SOA

In addition to the ongoing evolution of the basic SOA concepts and Web services technologies, architectures and infrastructures for SOA are evolving some common components. These components are increasingly forming the basis for packaged technologies that are offered by IT vendors. In this section, we discuss a few of the more obvious or important infrastructure and architecture

components.

Enterprise Service Bus

Although the basic Web services technologies, particularly SOAP/HTTP, can provide a certain quality of service to SOA by simply using existing Internet and intranet infrastructures, many enterprise requirements demand higher qualities of service, which require a dedicated infrastructure. This infrastructure must support both the established basic Web services technologies, established middleware communication technologies such as WebSphere MQ, and, eventually, emerging standards such as WS-ReliableMessaging.

Similarly, by just enabling or adding Web service interactions that use existing Internet and intranet infrastructure between systems in an architecture, many individual point-to-point integrations can be created. This has long been known to be difficult to maintain and evolve, hence the broad use of Enterprise Application Integration middleware supporting hub-and-spoke integration patterns.

These requirements to provide an appropriately capable and manageable infrastructure for Web services and SOA are coalescing into the concept of the

Enterprise Service Bus, which will be the subject of much of this redbook, from Chapter 4, “Enterprise Service Bus and SOA patterns” on page 73 onward.

Service directories and brokers

Although the UDDI directory specification was one of the earlier Web services specifications, it is implemented in only a small number of Web services

implementations. Many Web service or SOA implementations use either simpler, design-time directories (perhaps based around collaboration technology) or customized service directories (often using database technology).

However, a key benefit of SOA, particularly in enabling on demand solutions, is a more flexible selection of service providers. This can give businesses the choice of either providing their own service implementations to support their business processes or selecting from services provided by partner organizations. Some service providers may implement the service themselves, and others might be brokers for several end-service providers.

Similarly, as Web services standards mature to support increased security, trust models, and declarative policies, the use of services that are discovered

dynamically in public directories may become a more attractive option.

Several SOA implementations have already implemented some or all of these ideas, often with significant customized development. In time, products, standards, and architecture and design patterns are likely to evolve toward a number of well-defined intermediary models, including directories and brokers.

Service choreography

The desire to explicitly model and execute business processes is nothing new: Business analysis tools have been available for many years, and workflow function has been implemented in many technologies, from legacy systems to packaged applications to collaboration and groupware technology.

However, the emergence of service-oriented architecture and the Web services standards is opening new opportunities in this area. The SOA principles provide guidelines for defining services and processes that are likely to be more flexible and can be implemented in existing systems. The Web services technologies provide new, standard means of exposing and defining those services, and choreographing them into business processes.

Although this is still a new area, the appropriateness of SOA and Web services to long-standing requirements to model and automate processes is strong enough that this trend is likely to grow swiftly over the next few years.

Chapter 3. Web services and service-oriented architecture 65

User access to services

Service-oriented architecture specifies the use of interfaces to define encapsulated, reusable business function: in part, those interfaces identify a business function and specify the data required to interact with it. This is precisely the purpose of many application user interfaces: to enable users to identify a function, collect the data required to invoke it, and return the outcome to the user.

This correspondence has led to several interesting patterns emerging in providing user access to services and Web services:

򐂰 Portal technologies, such as WebSphere Portal Server, offer the capability to automatically present some Web services as portlets; however, this is often dependent on the addition of specific display-related information to the Web services description.

򐂰 The Oasis Remote Portlet Web Services specification provides an open standards means to exposed Web services in a manner that is suitable for display by portal technology, but the standard is relatively recent so full product support may take some time to emerge.

򐂰 The World Wide Web Consortium recently published the xForms specification for device-independent description of the data model for user interfaces. The content of xForms descriptions bears several similarities with that of WSDL descriptions of the data that is required by and returned from a service. If a service interface can be transformed manually or programmatically into an xForms definition, then xForms UI generators can be used to generate a variety of Web-based, desktop, or other UIs. The xForms specification can be found at:

http://www.w3.org/TR/xforms/