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:
Overview
SALT allows you to import external Web Services into Oracle Tuxedo Domains. To import external Web services into Oracle Tuxedo applications, a WSDL file must first be loaded and converted. The SALT WSDL conversion utility, wsdlcvt, translates each wsdl:operation into a SALT proxy service. The translated SALT proxy service can be invoked directly through standard Oracle Tuxedo ATMI functions.
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
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
SALT converts WSDL object models into Oracle Tuxedo models using the following rules:
Note:
For more information, see SALT Web Service Definition File Reference in the SALT Reference Guide.
Other Web service external application protocol information is saved in the generated WSDF file (including SOAP protocol version, SOAP message encoding style, accessing endpoints, etc.).
XML Schema definitions embedded in the WSDL file are copied and saved in separate .xsd files.
Each wsdl:operation object and its input/output message details are converted as theOracle Tuxedo service definition conforms to the Oracle Tuxedo Service Metadata Repository input syntax.
Table 4‑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:
SALT Supported Communication Patterns
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(3c) / tpacall(3c) / tpgetreply(3c)
These basic ATMI functions can be called with an Oracle Tuxedo typed buffer as the input parameter. The return of the call also carries an Oracle Tuxedo typed buffer. All these buffers conform to the converted outside Web service interface. tpacall/tpgetreply are not related to SOAP async communication.
tpgetcallinfo() retrieves HTTP headers associated with an application buffer using the GWWS gateway in FML32 format; tpsetcallinfo() performs the reverse (i.e., attach FML32 formatted HTTP headers to an application buffer to be sent to a remote HTTP (possibly SOAP) server).
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 the client application response queue as if it is a traditional native Oracle Tuxedo service.
TMQFORWARD enabled queue-based communication.
Oracle Tuxedo system server TMQFORWARD can accept queued requests, and sends them to SALT proxy services that have the same name as the queue.
For more information, see Oracle Tuxedo ATMI C Functions and File Formats, Data Descriptions, MIBs, and System Processes Reference.
SALT does not support the following Oracle Tuxedo communication patterns:
Oracle Tuxedo Outbound Call Programming: Main Steps
When the GWWS is booted and 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:
1.
2.
Note:
The wsdlcvt generated FML32 field table files are always used by GWWS. You must make sure the field name is unique at the system level. If two or more fields are associated with the same field name, change the field name. Do not forget to change Oracle Tuxedo Service Metadata Repository definition accordingly.

The base number field index in the generated FML32 field table must be changed from the invalid default value to a correct number to ensure all field indexes in the table are unique at the entire system level.
3.
Generate FML32 header files with mkfldhdr32(1).
4.
Boot the GWWS with correct FML32 environment variable settings.
5.
6.
For FML32 buffers, you must add each FML32 field (conforming to the corresponding SALT proxy service input buffer details), defined in the Oracle Tuxedo Service Metadata Repository ( including FML32 field sequence and occurrence). The client source may include the generated header file to facilitate referencing the field name.
7.
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 4‑2 lists possible SALT proxy service tperrno values.
 
GWWS internal errors. Check ULOG for more information.
Handling Fault Messages in an Oracle Tuxedo Outbound Application
All rules listed inthe WSDL file are 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.
Tux Mode is used to convert Oracle Tuxedo original error buffers returned with TPFAIL. The error buffers are converted intothe XML payload in the SOAP fault <detail> element.
XSD Mode is used to represent SOAP fault and WSDL file fault messages defined with Oracle Tuxedo buffers. The mapping rule includes:
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 description of 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 both the SOAP version and WSDL fault message.
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 file 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 4‑3 lists the outbound SOAP fault errbuf definitions.
 
If no wsdl:fault is defined, this field contains an XML field.
See Also
Oracle Tuxedo ATMI C Functions
File Formats, Data Descriptions, MIBs, and System Processes Reference

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