Introducing WebLogic Enterprise Connectivity

 

This section includes the following topics:

• What Is the WebLogic Enterprise System?

• CORBA and J2EE Development

• Domains, Transactions, and Transaction Contexts

• Environmental Objects

• IIOP, ISLs, ISHs, and RMI on IIOP

• For More Information About WLE

• What Is WebLogic Enterprise Connectivity?

• Key Features of WebLogic Enterprise Connectivity

• System Architecture

• Clients and Servers in the WLEC Component

• WLEC Connection Pools

• WLE Security Features Supported by the WLEC Component

• Security Context Propagation

• Connection Failure Handling

What Is the WebLogic Enterprise System?

The BEA WebLogic Enterprise (WLE) product enables you to build, deploy, and manage component-based solutions for your enterprise. The WLE product combines Object Request Broker (ORB) and online transaction processing (OLTP) functions with industry programming models such as Enterprise JavaBeans (EJBs), Common Object Request Broker Architecture (CORBA), and 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.

Figure 1-1 presents an overview of the WLE system.

Figure 1-1 The WLE System

The following topics introduce some of the WLE system terminology.

CORBA and J2EE Development

The WLE product supports two types of objects that you can access from WebLogic Server clients:

• CORBA objects

• J2EE objects-EJBs and remote method invocation (RMI) objects

You can access both types of objects from one WebLogic Server client. The steps for accessing each type of object are different.

CORBA Objects, IDL, Factories, and ORBs

Common Object Request Broker Architecture (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 WLE system supports C++ 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.

The Object Management Group (OMG) interface definition language (IDL) is a language that you use to describe CORBA objects. You write an IDL description of the objects that will be visible remotely, then run this 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.

J2EE, RMI, EJBs, and JNDI

J2EE is the Java 2 (previously called JDK 1.2) platform that provides a complete range of enterprise-class functionality for server-side computing. It is designed to provide an integrated application environment in Java for building enterprise-level n-tier applications.

Remote method invocation (RMI) is a Java-only version of CORBA. Instead of writing IDL to describe an object (like you do with CORBA), you run a program called rmic on your Java .class files. The rmic program generates stub and skeleton classes directly from the .class files.

Enterprise JavaBean (EJB) is an API specification for building scalable, distributed, component-based, multitiered applications. EJBs leverage and extend the JavaBeans component model to provide a rich, object-oriented transactional environment for developers creating enterprise applications.

The Java Naming and Directory Interface (JNDI) provides access to an EJB's home interface. The home interface provides access to the EJB.

Domains, Transactions, and Transaction Contexts

A WLE 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 WLE system provides the following environmental objects that enable client applications to use WLE system services:

• The Bootstrap object establishes communication between a client application and a WLE domain. It also obtains object references to the other environmental objects in the WLE 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 WLE transaction. The TransactionCurrent object is the WLE 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 TransactionCurrent object is available only for CORBA objects, not for EJBs or RMI objects.

• 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 objects, RMI objects, and bean-managed EJBs.

IIOP, ISLs, ISHs, and RMI on IIOP

Internet Inter-ORB Protocol (IIOP) is the standard protocol defined by the CORBA specification for interoperation among ORBs. A WLE 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 WLE object. Each WLE domain that supports remote clients has at least one ISL.

Figure 1-2 presents an overview of IIOP.

Figure 1-2 How IIOP Worked in the WLE System

RMI is a Java API for distributed object computing and Web connectivity. A client uses RMI to get a reference to an object that exists elsewhere on the network and invoke methods on the object as though it existed locally. RMI on IIOP is the WebLogic version of RMI implemented to use the CORBA IIOP protocol. RMI on IIOP enables clients of WLE domains to use JNDI to access EJBs and RMI objects.

For More Information About WLE

For more information about the WLE system, see the WLE documentation. If you are new to the WLE system, we recommend that you read Getting Started.

What Is WebLogic Enterprise Connectivity?

WebLogic Enterprise Connectivity (WLEC) is a component of WebLogic Server that enables you to use WLEC connection pools to call WLE objects (CORBA objects, EJBs, and RMI objects) from WebLogic Server clients (servlets, EJBs, JSPs, and RMI objects).

The rest of this section covers the following topics:

• Key Features of WebLogic Enterprise Connectivity

• System Architecture

• Clients and Servers in the WLEC Component

• WLEC Connection Pools

• WLE Security Features Supported by the WLEC Component

• Security Context Propagation

• Connection Failure Handling

Key Features of WebLogic Enterprise Connectivity

The key features of the WLEC component are:

• Pooled WLEC connections to a WLE system

• Multiple active WLE client transactions from a single WebLogic Server process

• Configuration of WLEC connection pools through the Administration Console

• Monitoring of WLEC connection pools through the Administration Console

• Support for the Secure Sockets Layer (SSL) protocol

• Security context propagation from WebLogic Server to a WLE domain

• Pool re-initialization at run time

System Architecture

Figure 1-3 illustrates the WLEC system architecture and its relationship to WebLogic Server and WLE systems.

Figure 1-3 The WLEC System Architecture

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

Clients and Servers in the WLEC Component

Internet clients are served by applications on WebLogic Server. These applications act as clients to WLE domains by way of the WLEC component. WLE domains provide the requested WLE 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 WLEC component uses WLEC connection pools to enable WebLogic Server clients to connect to WLE domains. A WLEC connection pool is a set of IIOP connections to a WLE 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 WLE objects and operations quickly.

WLEC connection pooling has the following features:

• Uses IIOP.

• Supports one WLEC connection pool for each WLE domain.

• Allows WebLogic Server to have multiple simultaneous active WLE transaction contexts. However, a thread in WebLogic Server can have only one active WLE client transaction context at a time. The WLEC component does not support nested transactions.

• Supports multiple concurrent requests on the same physical connection, each with its own security context.

• Allows you to re-initialize WLEC connection pools at run time.

WLE Security Features Supported by the WLEC Component

The WLEC component provides the following WLE security features:

• Authentication

  Authentication ensures that two communicating parties are authorized to communicate with each other. The WLE system supports username/password authentication 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 and for RMI on IIOP requests to EJBs or RMI objects.

The WLEC component does not support the WLE security API. For an explanation of why this is so, see the Security,section in Writing WebLogic Server Clients That Invoke WLE Objects.

Security Context Propagation

Security context propagation requires a WLEC connection pool. A WLEC connection pool is a pool of IIOP connections in which each network connection has been authenticated using a particular principal identity that is pre-determined by the system administrator. You can use either password authentication or certificate authentication to establish a WLEC connection pool.

As Figure 1-4 shows, a WLEC connection pool enables you to propagate security information from a client through WebLogic Server to the WLE system:

Figure 1-4 Security Context Propagation

Connection Failure Handling

The WLEC 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 WLEC 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 WLEC 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, it 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.