The following sections present the many ways of making BEA Tuxedo services available to Web based applications:
“Web accessible,” as used in the discussions that follow, means making BEA Tuxedo application services available to Web based applications. The following figure helps clarify the meaning of “Web accessible.”
A Web based client application may be a simple Web client, e.g. a Web browser displaying Hypertext Markup Language (HTML) pages to the end users or a Web client with SOAP engine that can initiating Web Service standard requests.
A Web application server may be a Web server or a cross between a Web server and an application server. The standard definition of a Web server is “a server software system that serves static content to a Web browser by loading a file from a disk and serving it across the network to a user’s Web browser. This entire exchange is mediated by the browser and server talking to each other using Hypertext Transfer Protocol (HTTP).” The standard definition of an application server is “a server software system that occupies a large chunk of computing territory between database servers and the end user, and often connects the two. An application server is sometimes referred to as a type of middleware.” The BEA Tuxedo system, itself, is essentially two high-performance application servers, a transaction processing application server and an object application server.
A Web application server serves Web clients one of two types of pages (documents): Hypertext Markup Language (HTML) pages or Extensible Markup Language (XML) pages.
Exposing Tuxedo services as Web services opens the application to the outside world without any application code changes. The application can be broken down into smaller modular components, or shared services, that can be shared by and used as components of distributed Web-based applications.
BEA provides both Tuxedo native solution and Tuxedo-Other BEA products integrated solution for exposure of Tuxedo Services as Web Services.
The Web services technologies and programmatic interfaces are being developed by the World Wide Web Consortium (W3C). Web services are based on HTTP and XML as well as the following relatively new XML-based Internet technologies:
The XML-based language for describing (1) the methods provided by a Web service, (2) the input and output parameters of the Web service, and (3) the instructions for connecting to the Web service. WSDL is the standardized way to describe a Web service to clients so that they can invoke it.
An XML/HTTP-based protocol for accessing services, objects, and servers in a platform-independent manner. SOAP is the standardized way to transmit data and Web service invocation calls between users and providers of a Web service.
A repository that stores descriptions, in a common XML format, about companies and the services they offer. UDDI is the standardized way for client applications to find a registered Web service and to register a Web service on an Internet server.
Web services communicate with clients, both end-user applications and other Web services, through XML messages transmitted by HTTP. Web services can reside on different computers and can be implemented by vastly different technologies, but they are packaged and transported using standard Internet protocols, thus making them easily accessible by any user on the Internet.
For information about the Web services technologies, see W3C - Web Services Activity.
BEA SALT is one of the latest add-ons to the Tuxedo product family. Created in 2006, BEA SALT is designed to provide a seamless Tuxedo solution of integrating Tuxedo applications and standard Web services application. BEA SALT allows external Web service applications to invoke native Tuxedo services (inbound), and conversely, allows Tuxedo applications to invoke external Web services (outbound). BEA SALT is a native Tuxedo Web service integration solution.
BEA SALT complies with most primary Web Services standards: SOAP 1.1, SOAP 1.2, and WSDL 1.1. With BEA SALT, Tuxedo applications can be easily exposed as Web Services.
The following figure shows the principal software components comprising BEA Tuxedo native Web Services solution to expose Tuxedo application services as Web services.
BEA SALT is the preferred product for exposing Tuxedo ATMI services as Web services. It reduces Tuxedo/Web Service integration costs and decreases conversion processes that may exist with other solutions for accessing Tuxedo services. It enables seamless connectivity between Tuxedo applications and external Web service applications.
BEA SALT provided Tuxedo system server (GWWS), connects with other Web service applications via SOAP over HTTP/S protocol. The GWWS server acts as a Tuxedo gateway process and is managed in the same manner as general Tuxedo system servers. Each GWWS server has bi-directional (inbound/outbound) capability. The GWWS server:
For information about BEA SALT, see.
The following figure shows the principal software components comprising a BEA Tuxedo-WebLogic integrated solution to expose Tuxedo application services as Web services.
Both Java and non-Java client applications (such as Microsoft .Net Framework clients) can invoke Tuxedo services exposed as Web services through WebLogic Server. The client application assembles a SOAP message describing the Web service it wants to invoke and includes all the necessary data, either in the SOAP body or in a SOAP attachment. The client then sends the SOAP message over HTTP to WebLogic Server, which executes the Web service by performing the following tasks.
The following figure shows the principal software components comprising a BEA Tuxedo-AquaLogic Service Bus integrated solution to expose Tuxedo application services as Web services.
AquaLogic Service Bus is an Enterprise-class service bus that connects, manages, and mediates interactions between heterogeneous services. To connect between SOAP client applications and Tuxedo ATMI services, you should deploy both SOAP connectivity components and Tuxedo domain connectivity components based on AquaLogic architecture.
For information about BEA Web services and BEA products, see:
Besides being made available as Web Services, BEA Tuxedo application services are also made available to Web client programs through a Web application server. Applications embedded in the Web Application Servers can access Tuxedo ATMI services through one of the following approaches:
BEA Jolt provides Internet access to Tuxedo ATMI services for both Web-browser and standalone Java clients. Using Jolt, Java programmers can build client applets and applications that remotely invoke existing and new Tuxedo applications, allowing secure, scalable, intranet/Internet transactions between client and server.
Using Jolt, Java programmers can also use HTTP servlets to perform server-side Java tasks in response to HTTP requests. This type of Jolt connectivity enables simple Web clients to access Tuxedo application services through any Web application server that supports generic servlets.
The Jolt class library provides programmers with a set of object-oriented Java language classes for accessing BEA Tuxedo ATMI services. The class library contains the class files that implement the Jolt API.
In addition to Jolt applets and Jolt standalone applications, BEA Jolt supports the following three types of Jolt client personalities for simple Web clients:
This Jolt client personality is a Jolt HTTP servlet, running in a Java Web application server environment (for example, BEA WebLogic Server), through which simple Web-browser clients can invoke Tuxedo ATMI services. Accessing Tuxedo ATMI services in this manner requires the installation of Jolt class packages
joltjse.jar on the machine running the Web application server.
A Jolt HTTP servlet uses Jolt session pool classes to invoke Tuxedo services on behalf of simple browser clients. Thus, the servlet handles all Jolt transactions on the Web server, which enables simple browser clients to invoke BEA Tuxedo services without directly connecting to the Jolt server and BEA Tuxedo.
This Jolt client personality is a customized version of Jolt JSE Connectivity for the BEA WebLogic Server. Accessing Tuxedo ATMI services in this manner requires the installation of Jolt class packages
joltwls.jar on the machine running BEA WebLogic Server.
|Note:||The Jolt client personality “WebLogic Connectivity for BEA Tuxedo” is also known as “BEA Jolt for BEA WebLogic Server.”|
The Jolt server implementation acts as a proxy for the Jolt client, invoking the BEA Tuxedo service on behalf of the client. The Jolt server accepts requests from Jolt clients and maps those requests into BEA Tuxedo service requests.
For information on configuring the Jolt server and the BEA Tuxedo server to work with Jolt, seein Installing the BEA Tuxedo System.
For common client and Web server deployment considerations, see Using BEA Joltand Using BEA Jolt with BEA WebLogic Server.
BEA Tuxedo services have been Web accessible through BEA WebLogic Server ever since BEA WebLogic Server release 5.1. The following BEA Jolt software and BEA WebLogic Server gateways are central to this accessibility:
Enables WebLogic Server 5.1 or later EJBs, JavaServer Pages (JSPs), servlets, and other WebLogic Server application servers to call Tuxedo ATMI services on behalf of WebLogic Server Web-browser clients.
Enables WebLogic Server 6.1 or later applications, such as servelets and other WebLogic Server applications, to call Tuxedo ATMI services or Tuxedo CORBA C++ objects on behalf of WebLogic Server Web-browser clients.
In addition to WTC, there is support for IIOP connections from WebLogic Server (WLS) via the WLS ORB and the Tuxedo ISL.
For details about using Jolt or WTC to achieve interoperability between BEA Tuxedo and BEA WebLogic Server, seeWebLogic Server” in BEA Tuxedo Interoperability.