<ENTERPRISE NAME>
<PLACE LOGO HERE>
<author><version><revision date>
This is a template for the Application Integration Implementation Specification. This page should be removed prior to publication of the specification. The template is a guide for the enterprise and should not be blindly followed. The organization should
Review the chapter in the book that refers to the template to understand its use.
Examine the template outline and determine what additions might be necessary based on unique organizational needs.
If absolutely necessary, remove any sections that will not apply. (The authors strongly discourage this practice.)
Save the template for future use.
Begin to develop the document.
Guidance is given for preparation of the document throughout the template.
Text shown as normal text should be utilized in the document. It may be modified as necessary.
Text shown in pointed brackets is either instructional guidance in the application of the document or a description of the type of information to be added and should be removed prior to publication.
Text shown in double pointed brackets is a placeholder for the insertion of text by the authors.
Headers and footers should be customized as necessary as a final step in the completion of the document.
Application Integration Implementation Specification
<This specification provides implementation guidance for the development of an application integration based solution.
Application integration represents a specific style of integration. This style is to solve problems where two or more applications communicate together to accomplish a given task. Types of problems that are well suited to application integration are
Coordinating actions and replicating transactions across multiple applications
Opening up legacy systems and extending them to the Web
Creating new user interfaces
Business-to-business transactions
Deploying applications to multiple mobile and hand-held devices
This section describes the specific technical problems that are being addressed in the implementation, and provides context for the specific implementation.>
<The scope of an application integration specification is limited to the specifics of the applications that are being integrated. This section of the specification includes organizational units, external organizations, users, and applications involved. It should also define the expected time frames and end result.>
<This section identifies all stakeholders in the implementation, including business managers who control all or part of the systems, the business manager responsible for implementation, system designers and architect(s), and the development team who will execute the implementation. Any other participants or stakeholders should also be identified, including their roles.>
<There are several basic implementation patterns for an application integration solution. This section should define the particular pattern that is being used and then provide details on the configuration of the specific components of the implementation.
These patterns are
Message broker
Enterprise Service Bus (ESB)
Legacy integration
B2B integration
Portals
Mobile integration>
<Message brokers are well suited to coordination across multiple applications, replication of transactions, and B2B applications.
The message broker implementation involves an integration hub that provides transformation services to convert the messages into the correct format for the receiving application. The broker provides intelligent routing to manage the complexity of moving the messages between applications, and translation and transformation, generally through proprietary graphical-mapping tools. Adapters provide interfaces into applications and are the points where applications can send or receive messages.
Message Broker Reference Architecture
The implementation table further defines the services identified in the implementation architecture. Revise the following template to define the particular implementation.>
Message Broker Implementation Table
<The ESB is more flexible and scalable than the message broker, but also more complex to implement. Until recently, there were no widely accepted standards in the industry. Web services make the service bus a more viable commercial approach to application integration. Essentially, the ESB solves the same set of business problems that a message broker does, but it has a different architecture.
The ESB provides connectivity services, including transport protocol, message protocol, message routing, and guaranteed delivery. ESBs also usually provide some basic data transformation, such as XML translation via XSLT style sheets, but additional translation and transformation tools may be necessary for complex data transformation requirements. The ESB has adapters or connecters into applications that provide interfaces into the application as the method of communication. These interfaces represent services that are provided. The services can be registered into a directory. Requests can be sent to specific locations or routed based upon rules.
Enterprise Service Bus Reference Architecture
The Enterprise Service Bus Implementation Table further defines the services identified in the ESB reference architecture. Modify the following template to define the specific implementation, adding additional services when needed.>
Enterprise Service Bus Implementation Table
<The goal is to integrate with the legacy data, application, or process noninvasively, without changing the legacy application. This can be done by creating a new interface to the legacy system. This section defines what type of interfaces will be used.
Database interfaces. Database-level adapters that allow front-end applications access to mainframe data through database calls native to the requesting application, including JDBC, ODBC, and ADO.
Messaging interfaces. If the integration includes transaction processing, a message interface can be used. This includes connectors for JCA and SOAP messaging, or proprietary solutions including IBM MQ Series and TIBCO Rendezvous on the mainframe.
Screen/report interface. Sometimes, the only way to access mainframe data is through the screen or report interface, also called screen and report scraping. They both work the same way. The 3270 screen or report provides a defined interface to legacy systems for extracting information to the screen or report. The interface technology captures those data bits, and redirects them to a Web browser.
Service interface. The service-level interface, also called legacy wrapping, enables mainframe processes and functions to be wrapped with a Web service, .Net, Java, or CORBA interface. Web service interfaces to mainframe processes and services provide the most adaptable and reusable method of legacy integration, but also the highest initial investment.
The Legacy Integration Implementation Table further defines the services identified in the Legacy Integration Reference Architecture. Modify the following template to define the specific implementation. Be sure to define what legacy functions are available.>
Legacy Integration Reference Architecture
Legacy Integration Implementation Table
<B2B integration usually includes application integration services, but also adds additional services required when integrating with applications external to the organization, including
B2B Connectivity through either a B2B server or an external exchange
Multiple connectivity options for partners including EDI, HTML, XML, and FTP
Additional B2B security for encrypting transactions, authenticating the sender, and ensuring nonrepudiation of the transaction.
Partner management, including processes, business rules, and service-level management.
Use the diagram on the facing page as a reference when defining your B2B implementation.
The B2B Implementation Table specifies all components of the B2B architecture, including how back-end integration will be accomplished. Modify the template on page 350 to define the specific implementation.>
B2B Integration Reference Architecture
Portal Integration Reference Architecture
<Portals provide integration at the glass. They are used to extend mainframe functionality to the Web, and provide customer-facing applications. Portals require extensive integration services. There are a number of different ways to provide portal integration. The portal can have point-to-point connections to each of the applications it integrates with. APIs, database interfaces, Web services, or adapters can be used. Portals can also be part of an application server solution, and the application server can provide the integration services. Message brokers and ESBs can also provide integration services to the portal. Lastly, when the portal requires real-time access to aggregated enterprise data, enterprise information integration (EII) can be used. Moreover, if the portal supports business transactions as well as data aggregation, a combination of technologies can be used. The Portal Integration Reference Architecture depicts the alternative integration services that can be used in a portal implementation. Each of the services in the dotted box can be implemented as the sole portal integration solution. Alternatively, EII can be combined with a message broker, ESB, or application server. Multiple types of interfaces may be used in a single implementation.
The Portal Integration Implementation Table defines all the technologies and services that will be implemented as part of the portal solution.>
Portal Integration Implementation Table
<The mobile integration pattern is similar to B2B integration. It includes back-end application integration, and a mobile integration server can take the same information from multiple source systems and flexibly format it for different target devices. Mobile integration reliability and security are key issues to pay attention to, because the mobile network is inherently unreliable and insecure.
Mobile Integration Reference Architecture
Mobile Integration Implementation Table
The Mobile Integration Specification Table, like B2B integration, may specify how integration to back-end systems will be implemented. Modify the following template to define the specific implementation. Be sure to include any additional services added for reliability.>
<In this section other services are identified. This could include security, transactional, persistence, or other types of services or rules. Integration implementations may involve a number of different patterns defined above and in other chapters in Part III of this book. In this section, describe any additional services that will be included in the implementation.>
<The appendix should list any reference documents used in the creation of the document so that its contents can be traced back to their sources if necessary. This should be broken down into internal documents and external documents. Internal documents are those that belong to the organization. External documents are items such as articles, whitepapers, Web sites, or product documentation.>