Table of Contents Previous Next PDF

Oracle Tuxedo ATMI Programming for Web Services

Oracle Tuxedo ATMI Programming for Web Services
This chapter contains the following topics:
Oracle SALT allows you to import external Web Services into Oracle Tuxedo Domains. To import external Web services into Oracle Tuxedo application, a WSDL file must first be loaded and converted. The Oracle SALT WSDL conversion utility, wsdlcvt, translates each wsdl:operation into a Oracle SALT proxy service. The translated SALT proxy service can be invoked directly through standard Oracle Tuxedo ATMI functions.
Oracle SALT proxy service calls are sent to the GWWS server. The request is translated from Oracle Tuxedo typed buffers into the SOAP message, and then sent to the corresponding external Web Service. The response from an external Web Service is translated into Oracle Tuxedo typed buffers and returned to the Oracle Tuxedo application. The GWWS acts as the proxy intermediary.
If an error occurs during the service call, the GWWS server sets the error status using tperrno, which can be retrieved by Oracle Tuxedo applications. This enables you to detect and handle the SALT proxy service call error status.
Converting WSDL Model Into Oracle Tuxedo Model
Oracle SALT provides a WSDL conversion utility, wsdlcvt, that converts external WSDL files into Oracle Tuxedo specific definition files so that you can develop Oracle Tuxedo ATMI programs to access services defined in the WSDL file.
WSDL-to-Tuxedo Object Mapping
Oracle SALT converts WSDL object models into Oracle Tuxedo models using the following rules:
For more information, see Oracle SALT Web Service Definition File Reference in the Oracle SALT Reference Guide.
Each wsdl:operation object and its input/output message details are converted as an Oracle Tuxedo service definition conforms to the Oracle Tuxedo Service Metadata Repository input syntax.
Table 5‑1 lists detailed mapping relationships between the WSDL file and Oracle Tuxedo definition files.
Invoking SALT Proxy Services
The following sections include information on how to invoke the converted SALT proxy service from an Oracle Tuxedo application:
Oracle SALT Supported Communication Pattern
Oracle SALT only supports the Oracle Tuxedo Request/Response communication patterns for outbound service calls. An Oracle Tuxedo application can request the SALT proxy service using the following communication Oracle Tuxedo ATMIs:
tpcall(1) / tpacall(1) / tpgetreply(1)
These basic ATMI functions can be called with an Oracle Tuxedo typed buffer as input parameter. The return of the call will also carry an Oracle Tuxedo typed buffer. All these buffers will conform to the converted outside Web service interface. tpacall/tpgetreply is not related to SOAP async communication.
Oracle Tuxedo server applications can use this function to forward an Oracle Tuxedo request to a specified SALT proxy service. The response buffer is sent directly to client application’s response queue as if it’s a traditional native Oracle Tuxedo service.
TMQFORWARD enabled queue-based communication.
Oracle Tuxedo system server TMQFORWARD can accept queued requests and send them to Oracle SALT proxy services that have the same name as the queue.
Oracle SALT does not support the following Oracle Tuxedo communication patterns:
Oracle Tuxedo Outbound Call Programming: Main Steps
When the GWWS is booted and Oracle SALT proxy services are advertised, you can create an Oracle Tuxedo application to call them. To develop a program to access SALT proxy services, do the following:
Managing Error Code Returned from GWWS
If the GWWS server encounters an error accessing external Web services, tperrno is set accordingly so the Oracle Tuxedo application can diagnose the failure. Table 5‑2 lists possible Oracle SALT proxy service tperrno values.
Handling Fault Messages in an Oracle Tuxedo Outbound Application
All rules listed in used to map WSDL input/output message into Oracle Tuxedo Metadata inbuf/outbuf definition. WSDL file default message can also be mapped into Oracle Tuxedo Metadata errbuf, with some amendments to the rules:
Rules for fault mapping:
There are two modes for mapping Metadata errbuf into SOAP Fault messages: Tux Mode and XSD Mode.
Each service in XSD mode (servicemode=webservice) always has an errbuf in Metadata, with type=FML32.
errbuf is a FML32 buffer. It is a complete descriptionof the SOAP:Fault message that may appear in correspondence (which is different for SOAP 1.1 and 1.2). The errbuf definition content is determined by the SOAP version and WSDL fault message both.
Parameter detail/Detail (1.1/1.2) is an FML32 field that represents the wsdl:part defined in a wsdl:fault message (when wsdl:fault is present). Each part is defined as a param(field) in the FML32 field. The mapping rules are the same as for input/output buffer. The difference is that each param requiredcount is 0, which means it may not appear in the SOAP fault message.
Other elements that appear in soap:fault message are always defined as a filed in errbuf, with requiredcount equal to 1 or 0 (depending on whether the element is required or optional).
Each part definition in the Metadata controls converting a <detail> element in the soap fault message into a field in the error buffer.
Table 5‑3 lists the outbound SOAP fault errbuf definitions.

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.