Corporate Info | News | Solutions | Products | Partners | Services | Events | Download | How To Buy

Introducing WebLogic Enterprise Connectivity

  What Is the WebLogic Enterprise System?
    CORBA and J2EE Development
      CORBA, Objects, IDL, Factories, and ORBs
      J2EE, RMI, EJBs, and JNDI
    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 System
    IIOP Connection Pooling
    WLE Security Features Supported by WLEC
    Security Context Propagation
    Connection Failure Handling
    What Happens at Server Startup?

  Related Documents
    Using WebLogic Enterprise Connectivity

What Is the WebLogic Enterprise System?

The BEA WebLogic EnterpriseTM (WLE) product enables you to build, deploy, and manage component-based solutions for your enterprise. WLE combines Object Request Broker (ORB) and online transaction processsing (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.

The following diagram shows an overview of the WLE system:

The following topics introduce some of the WLE system terminology:

  CORBA and J2EE Development
    CORBA, Objects, IDL, Factories, and ORBs
    J2EE, RMI, EJBs, and JNDI
  Domains, Transactions, and Transaction Contexts
  Environmental Objects
  IIOP, ISLs, ISHs, and RMI on IIOP
  For More Information About WLE

CORBA and J2EE Development

WLE supports two types of objects that you can access from WLS applications:

- CORBA objects
- J2EE objects—EJBs and remote method invocation (RMI) objects

You can access both types of objects from one application. 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 CORBA 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 Object Request Broker (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 environmental objects that enable client applications to use WLE system services. When used with WebLogic Enterprise Connectivity (WLEC), the WLE system provides the following environmental objects:

- Bootstrap establishes communication between a client application and a WLE domain. It also obtains object references to the other environmental objects in the WLE domain.

- FactoryFinder 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 at startup.

- TransactionCurrent enables a client application to manage a WLE transaction. TransactionCurrent is the WLE implementation of the CORBA Object Transaction Service (OTS), which supports multiple transaction models. Some operations that TransactionCurrent provides are begin(), commit(), rollback(), suspend(), resume(), and get_status(). TransactionCurrent is available only for CORBA objects, not for EJBs or RMI objects.

- UserTransaction 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. UserTransaction 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.

The following diagram shows an overview of IIOP:

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 BEA 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

See the WLE documentation. If you are new to the WLE system, we recommend that you look at Getting Started. You can see Getting Started on the Web.

What Is WebLogic Enterprise Connectivity?

WebLogic Enterprise Connectivity (WLEC) is a component of WLS that enables you to use IIOP connection pooling to call WLE objects (CORBA objects, EJBs, and RMI objects) from WebLogic ServerTM (WLS) 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 System
  IIOP Connection Pooling
  WLE Security Features Supported by WLEC
  Security Context Propagation
  Connection Failure Handling
  What Happens at Server Startup?

Key Features of WebLogic Enterprise Connectivity

The key features of WLEC are:

- Pooled IIOP connections to the WLE system

- Multiple active WLE client transactions from a single WLS process

- Configuration of IIOP connection pools by way of the weblogic.properties file

- Monitoring of IIOP connection pools through the WebLogic Console

- Secure Sockets Layer (SSL)

- Security context propagation from WLS to WLE

- Pool reinitialization at run time

System Architecture

The following diagram shows an overview of the WLEC system architecture and its relationship to the WLS and WLE systems:

For each WLE domain, WLS creates an IIOP connection pool if the IIOP connection pool is configured in the weblogic.properties file. WLS clients use the IIOP connection pool to access WLE objects in the domain, which can be on a remote machine and/or behind a firewall.

Clients and Servers in the WLEC System

Internet clients are served by applications on WLS. These applications act as clients to WLE domains by way of WLEC. WLE domains provide the requested WLE objects and send results back to WLS clients. WLS clients can then process the results, do some other work, and send the results to the Internet clients.

IIOP Connection Pooling

WLEC uses IIOP connection pooling to enable WLS clients to connect to WLE domains. An IIOP connection pool is a set of IIOP connections to a WLE domain. WLS creates the IIOP connection pools at startup and assigns connections to WLS clients as needed. IIOP 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, WLS applications can access WLE objects and operations quickly.

WLEC IIOP connection pooling has the following features:

- Uses IIOP.

- Supports one IIOP connection pool for each WLE domain.

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

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

- Allows you to reinitialize IIOP connection pools at run time.

WLE Security Features Supported by WLEC

WLEC supports the following WLE security features:

- Authentication ensures that two communicating parties are authorized to communicate with each other. The WLE system supports username/password authentication and certificate-based authentication.

- Confidentiality is the ability to keep communications secret from parties other than the intended recipient. It is achieved by encrypting all data.

- Integrity is a guarantee that the data being transferred has not been modified in transit.

- Secure Sockets Layer (SSL) is a protocol that 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.

WLEC does not support the WLE security API. For an explanation of why this is so, see the Security section in Implementing Applications That Use WebLogic Enterprise Connectivity.

Security Context Propagation

Security context propagation requires a trusted IIOP connection pool. A trusted IIOP connection pool is an IIOP connection pool 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 username/password authentication or certificate-based authentication to establish a trusted IIOP connection pool.

As the following diagram shows, a trusted IIOP connection pool enables you to propagate security information from a client through WLS to the WLE system:

Connection Failure Handling

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

- When WLS is booted.

  If no ISL defined in the primary address list is accessible at server startup, WLEC uses ISL addresses from the failover list.

- When an IIOP connection pool loses an active connection.

  When the pool loses a connection, WLS 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 IIOP connection pool does not require a lost connection to be reopened, it stays disconnected and other active connections are used instead.

What Happens at Server Startup?

At startup, WLS:

- Initializes the WLE system's ORB.

- Creates IIOP connection pools. For each configured IIOP connection pool, WLS creates a Tobj_Bootstrap object.

Copyright © 2000 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher. Last updated 4/25/00