EIS imports and exports are the means of creating services that use resource adapters typically to access EIS systems.
Integrating applications on Enterprise Information Systems (EIS) with those developed locally is a key feature of WebSphere® Integration Developer. Examples of EIS systems include Enterprise Resource Planning (ERP), mainframe transaction processing, and database systems. In the diagram that follows, we see some developed import and export components at work. A stock purchase service, StockPurchase, accesses an import component, CustomerCredit, to check on a customer's credit before purchasing some stock for him or her. The import component, created by the enterprise service discovery wizard, represents an application on a CICS® server. From the stock purchase service's perspective, the CustomerCredit import component is a local service. Similarly, the stock purchase service is periodically notified of stock price changes by an export component, StockPrice, which the stock purchase service interacts with as a local service. The export component, created by the enterprise service discovery wizard, represents an application on a PeopleSoft server. Another way of looking at an export component is to think of it as a subscription service listening to an external request from an EIS system. Since import and export components behave as a local services, there is no special management of them that you have to do. In both cases, appropriate resource adapters and binding information provide the means of interaction between the import and export components and the applications on the EIS systems.
Resource adapters in WebSphere Integration Developer are used within the context of an import or an export. You develop an import or an export with the enterprise service discovery wizard and, in developing it, include the resource adapter. An EIS import, which lets your application invoke a service on an EIS system, or an EIS export, which lets an application on an EIS system invoke a service developed in WebSphere Integration Developer, are created with a particular resource adapter. For example, you would create an import with a JD Edwards resource adapter to invoke a service on the JD Edwards system.
The information on creating imports and exports with the enterprise service discovery wizard and an associated resource adapter is contained in this section. However, the specific details of each resource adapter will be found in that resource adapter's product documentation not in the WebSphere Integration Developer information. In Prerequisites for working with the enterprise service discovery wizard, you are reminded to have that product documentation on hand as you develop your import and export and some links to such product documentation have been added to help you.
Since the focus of WebSphere Integration Developer is on the enterprise service discovery wizard, our documentation shows you the pattern of using this wizard regardless of the resource adapter you use. Most tasks that demonstrate the use of the enterprise service discovery wizard pick the PeopleSoft adapter to show how to use it. However, as the Pattern of importing and exporting services indicates, accessing any system or registry follows a similar approach. It is expected that once you understand the pattern, you will use the product documentation of your particular resource adapter for specific and necessary details as you create your import or export.
Finding an application on any EIS system and creating an import or export component based on it follows the same pattern using the same wizard. The enterprise service discovery wizard is the tool you use to find an application on an EIS system and then generate the code for the import or export component to represent it. You start the wizard by selecting it from the business integration perspective tools launched from the menu bar or by selecting it from a pop-up menu when you right-click the module you are working with.
Once launched, you select the resource adapter you will work with from a list. The list displays the resource adapters which you have imported into your workspace. Importing a resource adapter simply means clicking Import Resource Adapter and following some steps to locate the resource adapter, that is, the RAR file. These steps are shown in the task information for creating an import of export component. Then you proceed by identifying the EIS system you want the wizard to discover applications on. The wizard searches the EIS system, returns the information on the applications at the EIS system, and through some additional pages guides you through the creation of the import and export component you want.
The reference point of the initiation of the transaction is what separates an import component from an export component. With an import component, the transaction is initiated by the service created in WebSphere Integration Developer. In other words, your application is invoking a program on the EIS system and getting some data in return from it. With an export component, the transaction is initiated by the external EIS system. In other words, the application on the EIS system is the one initiating the transaction. Another way of looking at an export component created from an EIS system is to think of it as a subscription service listening to an external request from an EIS system. Export components can only be created for EIS systems that support initiating external function calls. CICS and IMS™ systems do not support initiating external function calls and hence export components cannot be created for them.
In addition to generating import and export components, the wizard also generates business objects representing data structures on the EIS systems. Several step-by-step walkthoughs of using the enterprise service discovery wizard to create import and export components based on applications from a variety of EIS systems are shown in the task information.
For J2EE Connector Architecture (J2C), import and export components are created in a module only. Also, they cannot be accessed module to module; that is, you cannot drop a J2C export component into the assembly editor of another module.
The Enterprise Metadata Discovery specification is a joint specification from IBM® and BEA. It has been influenced by the rapid acceptance of service-oriented architecture as the means of inter-application communication. To realize the benefits of a service-oriented architecture, it is critical to have easy interoperability with EIS systems. This specification introduces a new metadata discovery and import model for resource adapters and the enterprise application integration (EAI) tools framework. The model allows resource adapters to easily plug into an integration framework and improves the usability of adapters within the framework. Any resource adapter that complies with this specification can plug into any EAI tools framework that also supports this specification. Any EAI tools framework that supports this specification can use any resource adapter that implements this specification. Tools that support Enterprise Metadata Discovery specification have become the standard way to implement J2EE Connector Architecture (J2C)-based applications.
The enterprise service discovery wizard supports the specification. The wizard browses the metadata information of an EIS system in a process called discovery. Then the artifacts that are of interest to you are imported into a service description. The service description contains all the information required to generate an implementation of the service. It, in turn, can be deployed to an application server. In addition to generating a service, you may be able to edit the configuration of the resource adapter or service after it has been created and configured. The tools in WebSphere Integration Developer that perform this editing function, the assembly editor and the business object editor, are demonstrated in the task help.
The IBM WebSphere Adapters listed in the resource adapters section comply with the specification, with the exception of IBM CICS ECI Resource Adapter 6.0.1 and IBM IMS Connector for Java™ 9.1.0.2. The specification defines a common API that resource adapters use to expose services and business objects to tools for the generation of J2EE Connector Architecture (J2C)-based applications.
This specification means there is a single tool environment to support development of applications accessing multiple EIS systems using multiple adapters. For you it means that developing services using the enterprise service discovery wizard will consistently follow a similar development pattern regardless of the EIS system you access. The specification leverages the metadata capabilities found on many EIS systems, which provide descriptive information about the services available from the EIS system. Simply put, the specification provides a standard way for tools to access EIS systems using a variety of resource adapters.
Resource adapters provide a mechanism that allows for the integration of an existing EIS infrastructure with the WebSphere Process Server or WebSphere Enterprise Server Bus server. They provide a service-oriented approach to EIS integration. Resource adapters offer a consistent framework for access to back-end systems and their applications.
Selecting a resource adapter is the first choice you make when you use the enterprise service discovery wizard. The resource adapters that come with WebSphere Integration Developer, used to access CICS, IMS, JD Edwards, PeopleSoft, SAP and Siebel systems, are intended for development and test purposes only. This means you use them to develop and test your applications. Once you deploy your application, you will need licensed runtime adapters to run your application. However, when you build your service you can embed the resource adapter with your service. Your resource adapter licensing may allow you to use the embedded resource adapter as the licensed runtime resource adapter.
The resource adapters can be divided into two classes:
The following IBM WebSphere Adapters are supported in WebSphere Integration Developer:
CICS, IMS, JD Edwards, Oracle, PeopleSoft, SAP and Siebel resource adapters come with this product for development purposes only; that is, they can be used to develop and test an application. Once deployed to a production server, your application will need a licensed runtime resource adapter. Note that when you build your service you have the option of embedding the resource adapter with your service. If you use that option, your resource adapter licensing may allow you to use the embedded resource adapter as the licensed runtime resource adapter.
All resource adapters that come with the product can be found in this path: <installdir>\Resource Adapters
Check the documentation that comes with these resource adapters for details such as their availability on platforms such as Linux®.
To see a complete list of supported WebSphere Business Integration Adapters, go to WebSphere Adapters.
A series of articles shows how to configure a business process on WebSphere Process Server and invoke the business process whenever an event is notified by the WebSphere Business Integration Adapter. In the first article, you set up event notification. In the second article, you implement a Java component that sends a synchronous request message to the WebSphere Business Integration Adapter and receives a response from it. In the third article, you set up a one-way asynchronous request message from the WebSphere Process Server to the WebSphere Business Integration Adapter.
Binding information determines how a service connects to and interacts with an application. Bindings are also a critical part of an import and export component. Bindings determine specifically how the import and export components interact with clients outside the module where the import and export components reside. Bindings specify the message format and protocol details for a particular interface.
In the following diagram, we can see the variety of bindings available. When you use the enterprise service discovery wizard the EIS binding information is created for you. You can also use another tool, the assembly editor, to add or modify binding information. You will likely be interested in using JMS, MQ or MQ JMS bindings if reliability is a critical issue for you. Asynchronous communication using messaging queues is often preferred in business processes where reliability is a critical factor. In the task information, you are shown how to create JMS, MQ and JMS bindings from the top-down, creating the bindings for an import or export. There is a pairing of imports and exports with messaging bindings as you would expect from a message consumer and producer. You are also shown how to create bindings from the bottom-up, in which case the EIS bindings have already been created from the wizard with all the low-level details, and you modify them.
IBM Web Services bindings can also by used with import and export components. In the case of an import component only, a stateless session enterprise Java bean (EJB) binding can be used. If no binding is selected for an import or export component, the default is SCA for Service Component Architecture. It is used to import from or export to another module created with the same architecture.
For the import and export components created by the Enterprise Service Discovery wizard, Enterprise Information Service (EIS) bindings are the key ones.
We have mentioned that the key bindings when it comes to EIS systems are JMS and EIS. There are some important differences in how these bindings are created and when one is chosen over another. For example, JMS is used from a module to a module; that is, you can create an export component in a module with a JMS binding or you can create an import component in a module with a JMS binding. You cannot do this with an EIS binding. Since JMS is used for asynchronous communication, you can also use JMS as the binding between an external messaging source and a component in a module.
EIS bindings are used from an EIS system to an application or vice-versa. In the first case, you would develop an export component with an EIS binding. In the second case, it would be an import binding. In the task help, both cases are demonstrated using the enterprise service discovery wizard. Essentially, EIS bindings are used to access external EIS systems or for external EIS systems to access applications developed in WebSphere Integration Developer. See How the wizards and editors support J2C and JMS to see the particular wizards and editors used by EIS and JMS for creation and editing purposes.
Another wizard associated with the enterprise service discovery wizard is the enterprise data discovery wizard. It is used to discover data structures in programs and then generate business objects from them. This wizard can be helpful when you want to create one or more business objects for your EIS services and you have the EIS application code available locally on your computer. The wizard can save you the time of hand-coding these business objects.
The task information shows how to use the enterprise data discovery wizard to create a business object from a data structure. You start the wizard by selecting it from the business integration perspective tools launched from the menu bar or by selecting it from a pop-up menu when you right-click the module you are working with.
The wizards and editors are used to support J2C and JMS. In the task help, you are shown specifically how to use these tools. The tools can be divided into creating and editing as follows:
Using the enterprise service discovery and enterprise data discovery wizards results in artifacts generated into a module. A module is similar to a project container. There are two types of modules, a module called module for service component architecture artifacts, and a mediation module, which contains only one service component architecture artifact, a mediation flow component. In the first case, a module results in an application tested and deployed to the WebSphere Process Server. In the second case, a mediation module results in an application tested and deployed to either the WebSphere Process Server or the WebSphere Enterprise Service Bus server.
When and why would you use a service from an EIS import and export in a mediation module? A mediation flow component in a mediation module was designed to mediate, as its name implies, between services. The mediation flow in the component is similar to the flow-like constructs you would see in the assembly editor or process editor. The mediation flow is done independent of the services themselves. Mediation has several useful functions. You can use mediation when you need to transform data from one service into an acceptable format for a subsequent service. Logging is another useful function of a mediation, where messages are logged before being sent to the next service. Routing lets you route data from one service into an appropriate service determined by the mediation flow. In these cases and others described in Creating mediation flows, you could use mediation between a service needing to access EIS systems and services that provide access to EIS systems created by the enterprise service discovery wizard.