8.3.3 Infrastructure Conditions for the Application Ecosystem

From the technology perspective, the following conditions have to be achieved:

• Provide an enterprise-ready Web 2.0 platform.

Drive the architecture of Web 2.0 deep into the enterprise, including the organizational and development aspects described in Chapter 4, "A Methodology for Service Modeling and Design."

Deliver end-to-end quality of service (QoS) that is demanded by enterprise environments (transactions, security, reliability, availability, and so on) without compromising the simplicity of the REST/Web 2.0 paradigm.

• Establish a service provisioning for REST components.

Create a distributed infrastructure that is capable of hosting and managing millions of transient and situational applications.

Enable fine-grained, dynamic mediation, caching, acceleration, and discovery from inexact description. This is a challenge for the middleware, the ESB, and related infrastructure services—a semantics support in the repository.

Enable integration of "browser-based middleware" for end-to-end management of all elements.

• Care for security, provenance, and governance.

Build fine-grained distributed protection and rights management for both data and services.

Allow "real-time" monitoring of regulatory compliance, including alerts and notifications.

Enable provenance management in a remix-and-republish environment, matching the reuse promises of SOA.

Detailing all the listed items goes beyond the scope of this book. The items we mentioned and the collective thoughts we conveyed should help you build the ecosystem that is needed to gain the most from situational applications in the enterprise. At the time of this writing, several tools that support this approach are under development or being improved.

Further, we like to point to the IBM developerWorks and IBM alphaWorks sites where the individual solutions are discussed. Research results are presented and available for early users.

8.4 Benefits from SOA to Enterprise Operations

To determine the benefits to the enterprise operation, a look at the stakeholders is advised. The higher-level view lets one state that the market forces are aligning the stakeholders in the following ways:

• The end users want access to their preferred data and widgets even as they change their framework of choice.

• The content providers want their content to be available to as many users as possible (that is, on as many platforms as possible), but do not want to be saddled with providing different widgets for each framework.

• The gadget and framework vendors need content and widgets for their frameworks or middleware products to be viable.

This means for real online services, the markets of all three types of vendors have to come together and find a common ground. There are already widely accepted standards for the technology base, namely Web services.

For Web services standards definitions and ongoing activities, visit the W3C.org.

Now, need is based on this standard definitions for the contents, the processing, and the use of any item offered. Some of those definitions are developed as so-called industry models, dictionaries, or encyclopedias. They contain and define all essential elements of a certain industry. Others define a catalog of common services that can be used in various contexts across industries. Those might be used to link business partners together similar to the APIs for SWIFT (Society for Worldwide Interbank Financial Telecommunication) for international money transfers between banks and EDI (Electronic Data Interchange).

Having such industry standards in place results in advantages for all involved parties, because one can concentrate on the essentials rather than fight for naming something or insisting on certain attributes for an entity used by a service. As always, after awhile, vendors recognize the larger benefits for their platforms that stem from open standards (as opposed to trying to chain all involved parties to proprietary definitions).