Introducing WebLogic Enterprise Connectivity


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| Download Documentation \| Contact \| Glossary

\| WebLogic Server Doc Home \| WebLogic Enterprise Connectivity \| Previous Topic \| Next Topic \| Contents \| View as PDF

The following sections introduce WebLogic Enterprise Connectivity including:

The BEA Tuxedo CORBA Environment

The BEA Tuxedo product enables you to build, deploy, and manage component-based solutions for your enterprise. The BEA Tuxedo product combines the Object Request Broker (ORB) in the Common Object Request Broker Architecture (CORBA) and online transaction processing (OLTP) functions available in Application-to-Transaction Monitor Interface (ATMI). The result is a platform that enables you to deliver scalable, secure, and transactional e-commerce applications in a well-managed environment.

The following sections introduce some of the BEA Tuxedo CORBA terminology.

CORBA Objects in the BEA Tuxedo Product

CORBA is a language-independent specification that promotes an object-oriented approach to building and integrating distributed software applications. You can implement your business logic as CORBA objects in different languages. The CORBA environment in the BEA Tuxedo supports C++, Automation, and Java language bindings. For example, a banking application can have objects for customer accounts. These customer account objects can have operations for depositing, withdrawing, and viewing the account balances.

You use the Object Management Group (OMG) interface definition language (IDL) to describe CORBA objects. You write an OMG IDL description of your CORBA objects and run the OMG IDL through a compiler. The compiler generates stubs and skeletons.

A CORBA factory is an object that provides an operation for creating object references to another CORBA object. A server application uses CORBA factories to let client applications access CORBA objects that are implemented in the server application. When a client application needs to get a reference to a CORBA object that is managed by a server application, it typically gets that object reference from a CORBA factory.

An ORB is a communications bus that enables client applications to communicate with distributed objects that are managed by server applications. In a CORBA environment, applications do not need to include network and operating system information to communicate. Instead, heterogeneous client and server applications communicate with the ORB. The ORB delivers client requests to the appropriate server applications and returns the server responses to the requesting client application.

Domains, Transactions, and Transaction Contexts

A BEA Tuxedo domain is a group of objects, services, machines, and resources that you administer as a unit. You can set up domains based on characteristics such as application functions, security needs, or geographical locations. For example, one domain might consist of the objects, services, machines, and resources for a bank's customer accounts. The bank might have a separate domain for its employee and payroll resources.

A transaction is a set of operations based on business rules. The operations act as one logical unit, even if they are distributed geographically. By acting as one unit, either all the transaction's operations complete successfully (in which case the transaction completes successfully) or all the operations roll back (the transaction fails). For example, a transaction withdraws money from one customer's account and deposits it into another customer's account. This transaction consists of two operations. Both operations must succeed in order for the transaction to succeed.

A transaction context defines the scope of a transaction, and is shared by the objects that are participating in the transaction. A transaction context can consist of various types of data, such as local variables, locks, cursor positions, and file control blocks.

Environmental Objects

The CORBA environment in the BEA Tuxedo product provides the following environmental objects that enable client applications to use CORBA services:

The Bootstrap object establishes communication between a client application and a BEA Tuxedo domain. It also obtains object references to the other environmental objects in the BEA Tuxedo domain.
The FactoryFinder object enables a client application to find CORBA factories. A CORBA factory can create object references for CORBA objects. The factories available to client applications are those that register with the FactoryFinder object at startup.
The TransactionCurrent object enables a client application to manage a transaction. The TransactionCurrent object is the BEA Tuxedo implementation of the CORBA Object Transaction Service (OTS), which supports multiple transaction models. Some operations that the TransactionCurrent object provides are begin(), commit(), rollback(), suspend(), resume(), and get_status().
The UserTransaction object enables a client application to participate in a transaction. This environmental object is an implementation of the Sun Microsystems, Inc. Java Transaction Application (JTA) Programming Interface. The UserTransaction object is available for CORBA Java objects.

IIOP and the IIOP Listener/Handler

Internet Inter-ORB Protocol (IIOP) is the standard protocol defined by the CORBA specification for interoperation among ORBs. In the BEA Tuxedo CORBA environment, the IIOP Listener/Handler handles communication between the ORB and CORBA client applications. The IIOP Listener (ISL) manages incoming communications for remote CORBA clients. Each ISL has one or more IIOP Handlers (ISHs) associated with it. An ISL assigns client applications to ISHs and balances the incoming client loads across the ISHs. An ISH is a communications link between a client application and a CORBA object. Each BEA Tuxedo domain that supports remote clients has at least one ISL.

Figure 1-1 presents an overview of IIOP.

Figure 1-1 How IIOP Works in the BEA Tuxedo System

More Information About the BEA Tuxedo CORBA Environment

For more information about the CORBA environment in the BEA Tuxedo product, see the BEA Tuxedo documentation. If you are new to the BEA Tuxedo product, we recommend that you read the BEA Tuxedo Product Overview.

What Is WebLogic Enterprise Connectivity?

WebLogic Enterprise Connectivity is a component of WebLogic Server that enables you to use WebLogic Enterprise Connectivity connection pools (referred to as WLEC connection pools in the Administration Console) to call BEA Tuxedo CORBA objects from WebLogic Server clients (servlets, EJBs, JSPs, and RMI objects).

Key Features of WebLogic Enterprise Connectivity

The key features of the WebLogic Enterprise Connectivity component are:

Pooled WebLogic Enterprise Connectivity connections to a BEA Tuxedo CORBA application
Multiple active CORBA client transactions from a single WebLogic Server process
Configuration of WLEC connection pools through the WebLogic Server Administration Console
Monitoring of WLEC connection pools through the WebLogic Server Administration Console
Support for the Secure Sockets Layer (SSL) protocol
Security context propagation from WebLogic Server to a BEA Tuxedo domain
Pool reinitialization at run time

WebLogic Enterprise Connectivity System Architecture

Figure 1-2 illustrates the WebLogic Enterprise Connectivity system architecture and its relationship to WebLogic Server and BEA Tuxedo.

Figure 1-2 The WebLogic Enterprise Connectivity System Architecture

For each BEA Tuxedo domain, WebLogic Server creates a WLEC connection pool which is configured in through the Administration Console in WebLogic Server. WebLogic Server clients use the WLEC connection pool to access CORBA objects in the BEA Tuxedo domain which can be on a remote machine and/or behind a firewall.

Clients and Servers in the WebLogic Enterprise Connectivity Component

Internet clients are served by applications on WebLogic Server. These applications act as clients to BEA Tuxedo domains by way of the WebLogic Enterprise Connectivity component. BEA Tuxedo domains provide the requested CORBA objects and send results back to WebLogic Server clients. WebLogic Server clients can then process the results, do some other work, and send the results to the Internet clients.

WLEC Connection Pools

The WebLogic Enterprise Connectivity component uses WLEC connection pools to enable WebLogic Server clients to connect to BEA Tuxedo domains. A WLEC connection pool is a set of IIOP connections to a BEA Tuxedo domain. WebLogic Server creates the WLEC connection pools at startup and assigns connections to WebLogic Server clients as needed. WLEC connection pools are efficient because they let a limited number of connections serve many users. Because the overhead for creating connections is performed at startup, WebLogic Servers can access CORBA objects and operations quickly.

WebLogic Enterprise Connectivity connection pooling has the following features:

Uses IIOP.
Supports one WLEC connection pool for each BEA Tuxedo domain.
Allows WebLogic Server to have multiple simultaneous active BEA Tuxedo transaction contexts. However, a thread in WebLogic Server can have only one active client transaction context at a time. The WebLogic Enterprise Connectivity component does not support nested transactions.
Supports multiple concurrent requests on the same physical connection, each with its own security context.
Allows you to reinitialize WLEC connection pools at run time.

BEA Tuxedo Security Features Supported by the WebLogic Enterprise Connectivity Component

The WebLogic Enterprise Connectivity component provides the following BEA Tuxedo security features:

Authentication
Authentication ensures that two communicating parties are authorized to communicate with each other. The BEA Tuxedo system supports password and certificate authentication.
Confidentiality
Confidentiality is the ability to keep communications secret from parties other than the intended recipient. It is achieved by encrypting all data.
Integrity
Integrity is a guarantee that the data being transferred has not been modified in transit.
The SSL protocol
The SSL protocol establishes secure communications between client and server applications. SSL is provided for IIOP requests to CORBA objects.

Note: The WebLogic Enterprise Connectivity component does not support the CORBA security application programming interface (API) in BEA Tuxedo.

Security Context Propagation

Using WebLogic Enterprise Connectivity, a security context established in WebLogic Server can be used to establish a security identify in a BEA Tuxedo domain. This passing of security credentials is referred to as security context propagation.

Security context propagation requires a WLEC connection pool. In a WLEC connection pool, each network connection has been authenticated through a User identity that is defined by the system administrator of WebLogic Server. You can use either password or certificate authentication to establish a WLEC connection pool.

As Figure 1-3 shows, a WLEC connection pool enables you to propagate security information from a client through WebLogic Server to the CORBA environment in the BEA Tuxedo product.

Figure 1-3 Security Context Propagation

Connection Failure Handling

The WebLogic Enterprise Connectivity component provides connection failure handling by using two lists of ISL addresses for each WLEC connection pool: a primary list and a failover list. The WebLogic Enterprise Connectivity component provides connection failure handling in the following cases:

When WebLogic Server is booted.
If no ISL defined in the primary address list is accessible at server startup, the WebLogic Enterprise Connectivity component uses ISL addresses from the failover list.
When an WLEC connection pool loses an active connection.
When the WLEC connection pool loses a connection, WebLogic Server tries to reconnect by using other addresses from the primary address list. If all addresses in the primary list fail, WebLogic Server tries to reconnect using addresses from the failover list. Lost connections are restarted only when they are needed. If the current load on the WLEC connection pool does not require a lost connection to be reopened, it stays disconnected and other active connections are used instead.