|
|
|
Introducing 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
WLE supports two types of objects that you can access from WLS applications:
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:
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
The key features of WLEC are:
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:
WLE Security Features Supported by WLEC
WLEC supports the following WLE security features:
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:
If no ISL defined in the primary address list is accessible at server startup, WLEC uses ISL addresses from the failover list.
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:
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|