So far in this discussion, integration has been confined to application integration via component-based services, but integration is a much broader topic than this. When assessing the requirements for an architecture, several types or “styles” of integration need to be considered. You must consider the following:

• Application integration
• Integration at the end-user interface
• Application connectivity
• Process integration
• Information integration
• A build to integrate development model

Integration at the end-user interface is concerned with how the complete set of applications and services a given user accesses are integrated to provide a usable, efficient, and consistent interface. It is an evolving topic, and the new developments, for the near term, will be dominated by advances in the use of portal servers. While portlets can already invoke local service components via Web services, new technologies, such as Web Services for Remote Portlets, will enable content and application providers to create interactive services that plug and play with portals via the Internet, and thereby open up many new integration possibilities.

Application connectivity is an integration style concerned with all types of connectivity that the architecture must support. At one level, this means things such as synchronous and asynchronous communications, routing, transformation, high speed distribution of data, and gateways and protocol converters. On another level, it also relates to the virtualization of input and output, or sources and sinks, as you saw in EWA’s Channel and Protocol Handlers. Here, the problem is the fundamental way data moves in and out of, and within, the framework that implements the architecture.

Process integration is concerned with the development of computing processes that map to and provide solutions for business processes, integration of applications into processes, and integrating processes with other processes. The first requirement might seem trivial; that is, that the architecture allows for an environment within which the basic business problems can be modeled, but insufficient analysis at this level will spell doom for any implementation of the architecture, regardless of its technical elegance.

Integration of applications into processes might include applications within the enterprise, or might involve invocation of applications or services in remote systems, perhaps those of a business partner. Likewise, process-level integration might involve the integration of whole processes, not just individual services, from external sources, such as supply chain management or financial services that span multiple institutions. For application and process integration needs, technologies like BPEL4WS can be used, or the application framework can use a program configuration scheme such as the one seen in EWA. In fact, a higher-level configuration scheme can be constructed using BPEL4WS at a lower level, and then driven by an engine that provides more function than just flow management. Before any of this is built, however, you must first understand the architectural requirements, and then build the appropriate infrastructure.

Information integration is the process of providing a consistent access to all the data in the enterprise, by all the applications that need it, in whatever form they need it, without being restricted by the format, source, or location of the data. This requirement, when implemented, might involve adapters and a transformation engine, but typically it is more complex than that. Often, the key concept is the virtualization of the data, which might involve the development of a data bus from which data is requested using standard services or interfaces by all applications within the enterprise.

Thus, the data can be presented to the application regardless of whether it came from a spreadsheet, a native file, an SQL or DL/I database, or an in-memory data store. The format of the data in its permanent store might also be unknown to the application. The application is further unaware of the operating system that manages the data, so native files on an AIX or Linux system are accessed the same way they would be on Windows, OS/2, ZOS, or any other system. The location of the data is likewise transparent; because it is provided by a common service, it is the responsibility of the access service, not the application, to retrieve the data, locally or remotely, and then present the data in the requested format.

Lastly, one of the requirements for the application development environment must be that it takes into account all the styles and levels of integration that might be implemented within the enterprise, and provide for their development and deployment. To be truly robust, the development environment must include (and enforce) a methodology that clearly prescribes how services and components are designed and built in order to facilitate reuse, eliminate redundancy, and simplify testing, deployment, and maintenance.

All of the styles of integration listed above will have some incarnation within any enterprise, even though in some cases they might be simplified or not clearly defined; thus, you must consider them all when embarking on a new architectural framework. A given IT environment may have only a small number of data source types, so information integration might be straightforward. Likewise, the scope of application connectivity might be limited. Even so, the integrating functions within the framework must still be provided by services, rather than being performed ad hoc by the applications, if the framework is to successfully endure the growth and changes over time that all enterprises experience.

Page 4: Benefits of Deploying a Service-Oriented Architecture