|
|
This section includes the following topics:
Oracle SALT provides bi-directional connectivity between Tuxedo applications and Web service applications. Existing Tuxedo services can be easily exposed as Web Services without requiring additional programming tasks. Oracle SALT generates a WSDL file that describes the Tuxedo Web service contract so that any standard Web service client toolkit can be used to access Tuxedo services.
Web service applications (described using a WSDL document) can be imported as if they are standard Tuxedo services and invoked using Tuxedo ATMIs from various Tuxedo applications (for example, Tuxedo ATMI clients, ATMI servers, Jolt clients, COBOL clients, .NET wrapper clients and so on).
Oracle SALT proxy services are Tuxedo service entries advertised by the Oracle SALT Gateway, GWWS. The proxy services are converted from the Web service application WSDL file. Each WSDL file wsdl:operation object is mapped as one SALT proxy service.
The Oracle SALT proxy service is defined using the Service Metadata Repository service definition syntax. These service definitions must be loaded into the Service Metadata Repository. To invoke an proxy service from a Tuxedo application, you must refer to the Tuxedo Service Metadata Repository to get the service contract description.
For more information, see Tuxedo ATMI Programming for Web Services.
To support Tuxedo application and Web service application integration, the Oracle SALT gateway converts SOAP messages into Tuxedo typed buffers, and vice versa. The message conversion between SOAP messages and Tuxedo typed buffers is subject to a set of SALT pre-defined basic data type mapping rules.
When exposing Tuxedo services as Web services, a set of Tuxedo-to-XML data type mapping rules are defined. The message conversion process conforms to Tuxedo-to-XML data type mapping rules is called “Inbound Message Conversion”.
When importing external Web services as SALT proxy services, a set of XML-to-Tuxedo data type mapping rules are defined. The message conversion process conforms to XML-to-Tuxedo data type mapping rules is called “Outbound Message Conversion”.
For more information about SALT message conversion and data type mapping, see Understanding Oracle SALT Message Conversion.
Table 1-1 lists a quick index of Oracle SALT programming tasks. You can locate your programming tasks first and then click on the corresponding link for detailed description.
SCA components run on top of the Oracle Tuxedo infrastructure using ATMI binding allowing you to better blend high-output, high-availability and scalable applications in your SOA environment. The Tuxedo SCA container is built on top of Tuscany SCA Native and Tuscany SDO C++ ((Assembly: 0.96, Client and Implementation Model 0.95) and SDO (2.01)).
The ATMI binding implementation provides native Tuxedo communications between SCA components as well as SCA components and Tuxedo programs (clients and servers). Runtime checks will be encapsulated in an exception defined in a header (tuxsca.h) provided with the atmi binding. This exception (ATMIBindingException), is derived from ServiceRuntimeException (so that programs not aware of the ATMI binding can still catch ServiceRuntimeException) and thrown back to the caller.
SCA deployment is handled by the following build commands:
SCA clients can be stand-alone or part of a server, similar to Tuxedo ATMI clients. Components are first built using buildscacomponent and then Tuxedo-enabled using buildscaserver. SCA administration is performed using common Tuxedo commands (for example, tmadmin), and the scaadmin command for SCA-specific tasks.
|