Integration and Web Services
Application Integration Using Oracle9iAS Web Services
Suresh Kumar Neti, Sierra Atlantic Software Services Ltd.
Overview
Application Integration is fast becoming the number one item to worry about for most of the medium to large company CTOs. Without application integration, companies will not be able to leverage the information present in the ‘expanding’ enterprise repositories and may end up making incorrect decisions because of the inconsistent information.
Web services continue to be more of hype than hope. It is important to appreciate the application of the Web services in the enterprise and beyond. One of the areas where Web services are considered is for the integration of applications.
Oracle 9iAS has got the infrastructure for integration of the applications. This paper presents some of the challenges that are present with Web services based integration and explains how Oracle 9iAS Web services can be used to integrate applications. The paper also presents a case study of integration of Oracle Applications with SAP using the 9iAS Web services.
Application Integration
An enterprise performs best when it leverages the information that is present within the various repositories, across the enterprise. Since most of the applications present in the enterprise are not ‘open’ or ‘compatible’ to each other, additional effort is often required to integrate the various applications within the enterprise.
Need For Integration
There are several reasons for the integration of applications. The applications need to be integrated not only to keep the data across the organization consistent, but also to query the applications for the required information. The following are some of the important reasons for the need for the integration.
Multiple Applications
As the enterprises started their journey to automate their tasks, many applications appeared within the enterprise, often performing similar tasks but in different groups. In many cases, the different groups were unaware of the existence of similar applications elsewhere in the enterprise. Often, the different groups performed their own evaluation of the software and had their own budgets.
After a period of time, with the advent of the ERPs, some structure came in, but there were many tasks that the ERPs also did not handle or did not handle to the detail one would want. ERPs also imposed a set of rules and standards in the enterprise. ‘Customizations’ to ERPs are not always possible or found to be expensive. This has led to the emergence of the custom applications. As these applications are not usually designed by a single team for the entire enterprise, the various supporting applications often ended up being written in various languages using different databases and environments.
As the competitiveness and user requirements increased, new breed of applications – CRM, SCM, SRM, PRM etc. came up. The ERP vendors quickly reacted by adding or enhancing the functionality of their ERPs to match or compete with the specialized application vendors. This has also given rise to the best of the breed vs single application implementation debate. While having a single application that caters to all the functions has its own advantages – specifically with reference to the integration and consistency in terms of the business process implementation, a single application is often found to be lacking in the functionality. The best of the breed applications usually bring the integration problems along with them.
Multiple Sources Of Information
Information is captured at several points, often in different formats. For example, customer information may be captured at the following locations.
Web site, where customer registration information is captured
Telephone, information given by the customers when they call in for information / service
PDAs, information captured by the sales representatives
Email, information sent in by the customers
ERP Applications
CRM applications
When information is captured at multiple locations, unless the information is synchronized with all the repositories, the usefulness of such information is always a question.
Mergers and Acquisitions
Whenever a company merges or acquires another company, the new entity inherits all the features from its constituent companies. This also includes the IT infrastructure. Proper planning and integration of the various applications with each other must be done in order to capitalize on the strengths of the combined entity.
The amount of planning and re-design of IT infrastructure that is required for the merged entity is considerably high if the constituent entities have fairly evolved heterogeneous systems. Interfaces will be required to be written for the information flow across the system.
In a scenario where the constituent organizations have achieved the application integration using different middleware, ‘bridges’ across the middleware will have to be built for the applications to communicate across the middleware.
Extended Enterprises and Collaborations
With the enterprises getting larger and collaborations between the enterprises getting stronger, a strong need is felt for not only the integration of data but also the integration of the business processes. In this case, the partner facing applications at each enterprise need to be integrated or be interfaced to exchange messages.
Types Of Integration
Integration can be classified as Enterprise Application Integration (EAI) or Business to Business (B2B), based on whether the integration of the application is within the enterprise or if it is across the enterprises respectively.
EAI
The objective here is to have the various applications within the enterprise integrate seamlessly. By having an integrated application infrastructure, the business processes can be orchestrated to take advantage of the enterprise applications. The integration is usually near-real time. The integration is typically achieved using middlewares, that provide the features including ‘Guaranteed Delivery’ and application connectivity. Typically messages are exchanged between the applications asynchronously or synchronously, not only for information update, but also for querying the information. When the transaction volume is very high and if near real time synchronization is not important, the messages can also be exchanged across the applications in a batch mode.
Data level integration takes care of the synchronization of the various repositories within the enterprise. More mature enterprises go in for business process level integration. Using the Business process modeling tools, the business process within the enterprise can be modeled to eliminate the redundancies in the organization process flow and increase the effectiveness.
B2B Integration
B2B Integration helps the organizations to collaborate effectively and reduce the duplication of tasks. The integration happens across the firewalls. The messages are usually exchanged in the form of documents. As the exchange is across the firewalls the security, transactional issues and reliability of the information exchange become important.
Web services
Web services arrived amidst a lot of hype and were expected to solve many of the problems associated with the application collaboration and applications running on the different platforms. As the Web services leverage the industry standards, the interoperability issues between the applications are eliminated.
What are Web services?
Web service as defined by W3C is as follows.
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
Any functionality or service can be exposed as a Web service. For any service to be exposed as a Web service,
The functionality should be described in Web Services Description Language (WSDL)
Service consumers interact with the Web service using SOAP messages
Optionally, The list of the available Web services can be stored in UDDI registries. The service provider needs to register in the UDDI registry.
The UDDI Registry is optional and contains all the Web services that are published by the various Web service providers. UDDI registries are two types – private registries that are internal to the enterprise or public registries that are available publicly.
Typical Applications of Web services
Web services are appealing because of the simplicity. It opens up a possibility to expose any business functionality for the others to consume. Any existing functionality can be exposed as a Web service by writing wrapper code using the many tools that are now available for the Web service development. The invocation of the Web services can be done without worrying about the platform specific and implementation features.
The following are typical examples of implementations of Web services.
Sending weather updates
Conversion Services (Eg., Currency conversion)
Check the Item availability at the warehouses
Placing Purchase Orders and getting the confirmation
A marketplace where buyers submit their requests and sellers place the responses to the requests
Placing a request for ‘specialized web search’ and get multiple responses from different search engines
‘Conversation’ between buyers and sellers involving multiple messages
Issues with Web services
Having looked at the possibility of the usage of Web services, one may easily conclude that the Web services can be used for solving problems of practically any nature. So, why not use the same for integration of applications. One needs to note that there are still some issues of using Web services that need to be kept in mind, when used for enterprise application integration involving multiple transactional applications. Also, areas like load balancing and fault tolerance need to be addressed at the application layer. Standards are evolving to address these issues and hopefully they will be addressed in the near future.
Support for Transactions
Web services currently do not support transactions. Standards like WS-Transaction and WS-Coordination are being developed in this direction.
Security
Use of https provides security at the transport level. WS-Security standard is evolving to take care of the other security issues related to Web services.
Reliability
There is no reliability of the messages being exchanged using the Web services. This would mean that the Web services do not offer standard mechanism for reliable integrations and would involve efforts for achieving the reliability. However, standard mechanisms for exchanging secure and reliable messages in a Web services environment have been proposed.
Support for Workflow
Web services standards do not yet support workflow requirements. Also, since Web services environments are implementation specific, there are no standard design tools available for the business process modeling.
Oracle 9iAS Web services for Integration
Oracle 9iAS supports the development of Web services. These can be used to develop Web services. An approach to developing and implementing integrations using these Web services is also explained below.
Features
Oracle 9iAS supports two different Web services options.
J2EE based Web services environment built into Oracle 9iAS OC4J
Apache SOAP (ORACLE SOAP) based Web services environment
OC4J is the recommended approach for the Web service implementation using Oracle 9iAS.
Oracle 9iAS infrastructure has support for all the phases in the development to deployment of the Web services. The following are the salient features of the environment offered.
Development environment and tools for easy building of Web services: The existing Java or PL/SQL stored procedures can be implemented as Web services.
Automatic generation of code transparently
UDDI Registry: Oracle 9iAS comes with a standards based registry, that can be used as either a public or private UDDI.
Common Runtime Services: Oracle 9iAS has a common runtime and brokering environment for J2EE applications and Web services. The Web services inherit the various services available with the J2EE container.
Easy deployment
Monitoring and Administration features
Integration between Oracle Applications and SAP Using 9iAS Web services
An approach for integration of Oracle Applications with SAP (and other applications) is detailed below.
Architecture
The high level architecture of the integration between Oracle Applications and SAP using Oracle 9iAS Web services is shown below. This is based on the architecture of Sierra Atlantic’s Application Networks®.
The various components in the above figure are explained below.
Integration Director: This is built using the Oracle 9iAS infrastructure using the OC4J. It orchestrates the entire integration. It contains the various services that are required for the integration. As the messages are published to the Integration Director, the messages are passed through the various integration services. It accesses the Integration Repository for the various integration data and meta-data. The various components within the Integration Director are as follows.
- Message Listener: This listens to the various messages that are arising from the various applications and that are published. It listens to the SOAP messages sent by the other applications. For messages originating in Oracle Applications, it uses the native connectivity to the Oracle Applications database. The messages are read and sent to the Routing service.
- Routing Service: The Routing service reads the message coming from the application and based on the message type and the intended target applications for this message (stored in the Integration Repository), updates the target information in the message. If required, multiple copies of the message are generated for the multiple targets.
- Object Cross Reference Service: The same object (Eg., Customer) can be stored in multiple applications, but with different Object Ids. For the updates on the object to be propagated, it is required that the Object Cross Reference information be generated and maintained. This is the functionality of Object Cross Reference Service. Based on the operation on the object (create or update) the service generates or updates the cross-reference information in the message.
- Application Value Mapping Service: There are instances when the same values are referred differently in the various applications. For example, country code for United States of America may be stored as USA in one application and US in the other application. But both of them refer to the same value. Application Value Mapping service identifies if any changes are required in the message and makes the required changes to the message. This decision is based on the target application, object being sent and the application value maps stored in the Integration Repository.
- Message Publisher: Based on the target, the message publisher publishes a message. If the message is an Oracle outbound message, it will publish a SOAP message using HTTP to the intended target application. Else, the Oracle interface tables are populated.
SAP Integration Listener: The SAP Integration Listener consists of two components.
- Inbound Listener: It listens to the SOAP messages from Integration Director, pre-validates the content of the message, converts them to IDOCs or BAPI calls and posts them to SAP using JCo. After the message is published successfully to SAP, a confirmation is sent back to the Integration Director via the Outbound Listener. The confirmation message is used for guaranteed delivery purposes as well as to update the Object Cross Reference information.
- Outbound Listener: Once the IDOCs are generated in SAP (implying object updates), the Outbound listener reads them, converts them to SOAP messages and posts them using HTTP to the Integration Director.
Integration Repository: This contains the Routing Rules, Object Cross Reference information, Application Value maps and the other data required for the integration.
Implementation Details
The Oracle9iAS Web Services can be implemented as any one of the following.
- Java Classes (stateful and stateless)
- Stateless Session Enterprise Java Beans (EJBs)
- Stateless PL/SQL Stored Procedures or Functions
The components in the Integration Director can be built as Oracle9iAS Web Services, implemented using Java classes. Oracle9iAS supplies Servlets to access the Java classes which implement a Web service. The Servlets handle requests generated by Web service clients, run the Java methods that implement the Web services and return results back to the Web service clients.
The various components in the Integration Director can be implemented as the Java Classes, with the Message Listener’s receiveMessage() method exposed to the clients.
To deploy the Web service, we need to
- Update the web.xml to support Java Web services by adding the <servlet> and <servlet-mapping> tags.
- Prepare the .war file for all the Java Class Web services. All the supporting Java classes must be included.
- Prepare the .ear file for the Java Class Web services after including application.xml and the .war file
- Deployment of the Web services can now be done like any other standard J2EE application.
Advantages
- The integration is not limited to Oracle Applications and SAP. Any custom applications, capable of processing SOAP messages can participate in the integration. For each new application, an Application Integration Listener is required. If the application supports SOAP, then the Application Listener may not be required.
- Routing of the various Objects can be changed at runtime.
- Application complexities are shielded by the Integration Listeners.
- Application upgrades can be taken care by the updates to the Integration Listeners.
- Features can be added to this infrastructure to take care of most of the typical integration requirements.
- Synchronous and asynchronous integration requests can be handled.
- Oracle 9iAS development and runtime environments could be used for rapid development and deployment.
References