Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Application Integration Using Oracle 9iAS Web Services by hcj


									                                                                                               Integration and Web Services

                               Suresh Kumar Neti, Sierra Atlantic Software Services Ltd.

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
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
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.
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.
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.
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.

                                                                                                             Paper # 36811
                                                                                                 Integration and Web Services

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.
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
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.
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.
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 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.

                                                                                                               Paper # 36811
                                                                                                            Integration and 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.
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
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.

                  Web service Requestor

                                                                           2. Search

                                     3. Interact

                                                                                                 UDDI Registry
                                                              1. Publish Web Service
                    Web service Provider

                                    Figure 1: Steps in creation and invocation of Web services

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.
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

                                                                                                                           Paper # 36811
                                                                                               Integration and Web Services

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
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.
Web services currently do not support transactions. Standards like WS-Transaction and WS-Coordination are being
developed in this direction.
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.
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.
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 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.
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.

                                                                                                             Paper # 36811
                                                                                                              Integration and Web Services

 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
 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
An approach for integration of Oracle Applications with SAP (and other applications) is detailed below.
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®.


       Oracle                                 Integration                                    SAP Integration
     Applications                              Director                    SOAP
                                                                                                Listener                     SAP
                                              Oracle 9iAS)


                                                                                             Custom App 1
                                                                                              Integration                Custom App 1


                                                                                              Custom App n
                                                                                               Integration               Custom App n

                      Figure 2: High Level Architecture for Integration of Applications using Oracle 9iAS Web services

                                                                                                                              Paper # 36811
                                                                                                        Integration and Web Services

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             Routing Service                       Object Cross
                                                                                    Reference Service

                App Value Mapping               Message Publisher

                                 Figure 3: Components of the Integration Director

        oMessage 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.
      o 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.
      o 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.
      o 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.
      o 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.
         o 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.

                                                                                                                      Paper # 36811
                                                                                               Integration and Web Services

               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.
          o 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.
The Oracle9iAS Web Services can be implemented as any one of the following.
         1. Java Classes (stateful and stateless)
         2. Stateless Session Enterprise Java Beans (EJBs)
         3. 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
         1. Update the web.xml to support Java Web services by adding the <servlet> and <servlet-
             mapping> tags.
         2. Prepare the .war file for all the Java Class Web services. All the supporting Java classes must be included.
         3. Prepare the .ear file for the Java Class Web services after including application.xml and the .war file
         4. Deployment of the Web services can now be done like any other standard J2EE application.
1. 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.
2. Routing of the various Objects can be changed at runtime.
3. Application complexities are shielded by the Integration Listeners.
4. Application upgrades can be taken care by the updates to the Integration Listeners.
5. Features can be added to this infrastructure to take care of most of the typical integration requirements.
6. Synchronous and asynchronous integration requests can be handled.
7. Oracle 9iAS development and runtime environments could be used for rapid development and deployment.

1. Oracle 9i Application Server – Web Services Developer’s Guide
2. Web Services Architecture Usage Scenarios – W3C working draft

                                                                                                             Paper # 36811

To top