| As discussed earlier, every application server vendor must satisfy two criteria. The first is compliance with the J2EE specification, also known as J2EE certification, as well as other leading Internet standards. The second is the implementation of additional infrastructure services to support the J2EE Application Programming Model (see Figure 9.5), which has the following components : Figure 9.5. The J2EE Application Programming Model.  -
The presentation layer is responsible for managing the user interfaces of applications, including desktop applications, Web browsers, and pervasive devices. -
The business layer hosts the business logic for the application. -
The integration layer provides connectivity with enterprise systems, databases, and other application-relevant data sources. You will find that to support the J2EE Application Programming Model, application server vendors go beyond J2EE to ensure that their application server is the best of breed. In complete compliance with the J2EE Application Programming Model, BEA WebLogic Server 7 has a three-layered architecture, with reliability , availability , scalability , and other QoS features extended across the presentation, business, and integration layers , as illustrated in Figure 9.6. Figure 9.6. The high-level technical architecture of WebLogic Server 7.  The following sections discuss each architectural layer of WebLogic Server as well as the value-added features that continue WebLogic Server's success in the application server marketplace . The Presentation Layer The presentation layer of WebLogic Server is primarily responsible for managing interactions with a broad array of end-user Web applications, which communicate with WebLogic Server through client types such as -
Web browsers, also known as thin clients , which send HTTP requests and receive HTTP responses for static HTML or dynamic Web pages generated by Java servlets and JSP. -
Thick clients, such as Java, CORBA, and COM+ clients, which communicate with WebLogic Server using RMI, RMI-IIOP, and DCOM, respectively. -
Pervasive devices, which include wireless phones, PDAs, smart appliances, and other emerging remote clients that communicate with the server via specific and usually very compact protocols. An example of such a protocol is the Wireless Markup Language (WML), an XML-based language optimized for wireless devices. WebLogic Server can generate WML pages from servlets and JSP. Note In interactions in which clients are typically other Enterprise Information Systems (EISs), such as Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Human Resource (HR), and Customer Relationship Management (CRM) systems, connectivity is achieved through WebLogic Server's integration layer.
WebLogic Server implements the presentation layer through an integrated high-performance Web server, which runs in the same process as the application server, as illustrated in Figure 9.7. It is the Web server that implements the Web container, the execution environment for the presentation J2EE components (servlets and JSP). WebLogic Server also provides native plug-ins for the Apache, iPlanet, and Microsoft IIS Web servers, which enables you to leverage these Web servers to deliver the static content (HTML pages) of your Web application and, hence, distribute the workload of your Web application across the WebLogic and Web server, respectively. Figure 9.7. The presentation layer of WebLogic Server.  Note The presentation layer can also be extended to be a Web portal through the WebLogic Portal product, which can then be used to aggregate and share content.
Beyond the basic presentation layer support for Web applications, which primarily involves hosting and serving static or dynamic content, WebLogic Server also provides the following features: -
Clustering ” WebLogic Server can be deployed in a cluster of multiple-server instances to achieve scalability and high availability. A WebLogic Server cluster appears to its clients as a single server, but it is a group of servers coordinating their processing as a single "super" server. Clustering provides the capability to fail over from a malfunctioning server to a functioning server, thus insulating clients from hardware or power failures through the elimination of a single point of failure. -
High availability with transparent failover ” WebLogic Server enables the data contained in Web components to be replicated across multiple machines. Hence, in the event of a failure, the current client session information is maintained . In addition to disk-based persistence, WebLogic Server can also use a very efficient in-memory replication mechanism for a client's session state to achieve the highest level of performance and scalability. -
Load balancing ” Incoming requests can be distributed intelligently across multiple instances of WebLogic Server in a cluster configuration through load-balancing appliances or by using the WebLogic or third-party Web server as a proxy. Note The capability to efficiently load-balance requests is a critical aspect to any failover, scalability, and high-availability solution.
 For detailed information on how to design and implement WebLogic Server clustering solutions, see Chapter 25, "Implementing Highly Available and Scalable Solutions Using the WebLogic Cluster," p. 837 .
-
Virtual hosting ” WebLogic Server can host multiple Web sites in a single application server. For example, organizations sharing a WebLogic server can have different domain names , with Web servers accessible as www.company1.com and www.company2.com , without requiring users to know any extra path information. -
Dynamic page-level caching ” WebLogic Server provides page-level caching for entire JSP pages, static pages, pages generated via servlets, URLs, and other file types, without requiring any code changes to the application. The caching features are enabled via the WebLogic Administration Console. By using the WebLogic JSP cache tags, you can also cache specific portions of a JSP page; this capability was first introduced in WebLogic Server 6.x. -
Integrated management ” The WebLogic Web server can be fully managed through the Web-based extensible WebLogic Administration Console. The Business Layer The business layer of WebLogic Server is responsible for providing the necessary infrastructure services to the business logic components of a J2EE application, which, as defined by the J2EE specification, are represented through EJBs. EJBs are the enterprise Java components that enable developers to build scalable, portable, and reusable server-side business logic. Three major types of EJBs are defined by the J2EE EJB 2.0 specification: -
Session beans ” These beans are process or control objects specific to a particular client and are responsible for controlling workflow, managing processes/ tasks , or coordinating processes between entity beans. Session beans can be -
Stateless, which execute a request and return a response without saving any state information -
Stateful, which are an extension of a client because they perform tasks and maintain state information on behalf of a client -
Entity beans ” These beans are data objects that act as nouns and usually represent real-life objects, such as bank accounts, purchase orders, employees , companies, and vendors. They are in-memory objects that physically map to data stored in an underlying relational database or legacy system. Persistence can be manually performed by the developer (bean-managed persistence) or by WebLogic Server (container-managed persistence). Typically, session beans call entity beans to achieve their desired actions, such as a purchase order approval router (session bean) that deals with purchase orders (entity beans). -
Message-driven beans ” These beans are messaging objects designed to receive and route messages from clients to other EJBs. For example, a logging service can receive logging messages and call a session bean to perform the actual logging. As illustrated in Figure 9.8, WebLogic Server implements the business layer through the EJB container, which handles the underlying infrastructure services, such as concurrency, security, availability, scalability, persistence, transaction management, and object life-cycle management. Figure 9.8. The business layer of WebLogic Server.  Beyond the basic EJB support, WebLogic Server also provides the following features to ensure that EJB deployments are robust: -
Full EJB 2.0 support ” The EJB container is fully compliant with EJB 2.0; it also supports EJB 1.1. -
Dynamic query support ” Dynamic queries enable you to construct and execute queries programmatically in your application code. They prevent the need to hard-code finder queries into an EJB's deployment descriptor. -
EJB WebLogic QL enhancement support ” WebLogic QL is a WebLogic-specific extension of the EJB 2.0 query language known as EJB QL, with support for the following enhancement features: -
Message-driven bean migratable service support ” This feature allows the message-driven bean and the JMS server to migrate to another server in the same cluster, which expedites message-driven bean recovery. -
EJB CMP multiple table mapping support ” Multiple table mapping enables you to map a single EJB to multiple DBMS tables within a single database. -
Optimistic concurrency support ” This feature is a new concurrency strategy offered by WebLogic Server, which provides optimistic support with and without caching enabled for the bean. The bean guarantees that the data is consistent by making sure that it was not modified before committing the transaction. -
ReadOnly entity concurrency support ” This feature allows WebLogic Server to activate a separate instance of a read-only bean for each transaction needing concurrent access to that bean. -
EJB instance pooling ” This feature allows WebLogic Server to preload a given number of EJB instances and prepare them for use, thereby saving time by not having to create a new EJB instance for each request. When a client is done with an EJB instance, the server puts it back into the pool for future reuse. This feature also helps limit the load on the server by giving the administrator control over the maximum number of beans in the pool. -
EJB clustering ” This feature allows EJBs to be deployed into a WebLogic cluster, where each bean can be distributed across the cluster and located by means of distributed naming and directory facilities. Leveraging the clustering capabilities of WebLogic Server enables EJB deployments to benefit from enhanced scalability and reliability. -
EJB high availability with transparent failover ” WebLogic Server can replicate the state of EJBs across a cluster of separate physical WebLogic Server processes, creating redundancy in case of failure. WebLogic Server transparently fails over to a backup machine in the cluster in the event of a failure. -
EJB load balancing ” WebLogic Server can route requests from remote clients to EJB components by using a predetermined algorithm or custom algorithm. This results in scalability beyond a single machine and, using BEA plug-ins, can work with WebLogic Server's Web server as well as other vendors' Web servers. -
Combined caching support ” This feature enables you to configure a single cache for use with multiple entity beans. -
Relationship caching support ” This feature improves the performance of entity beans by loading related entity beans into a cache and avoids multiple queries by issuing a join query for the related beans. Note Relationship caching works only with one-to-one and one-to-many relationships.
-
Bulk insert support ” This feature increases the performance of Container-Managed Persistence (CMP) bean creation by enabling the EJB container to perform multiple database inserts for CMP beans in one SQL statement. The Integration Layer As illustrated in Figure 9.9, the integration layer of WebLogic Server is responsible for providing interprocess communication, messaging, and transactional access integrity to your organization's EIS. For example, you can use the integration layer to access data and information sources, such as RDBMSs, ERP systems, CRM systems, and mainframes. Alternatively, you can also use the integration layer to integrate your J2EE applications with existing technology investments through JMS, J2CA, and Web services, future-proofing the existing information infrastructure. Figure 9.9. The integration layer of WebLogic Server.  BEA extends the integration features in WebLogic Server through the WebLogic Integration product to include a full array of solutions for Enterprise Application Integration (EAI), business-to-business (B2B) collaboration, and Business Process Management (BPM). The following sections describe the infrastructure services the integration layer of WebLogic Server provides. Database Connectivity WebLogic Server provides connectivity and access to relational databases through Java Database Connectivity (JDBC), as illustrated in Figure 9.10, and supports any database that has a JDBC 2.0 “compliant driver. The JDBC driver (jDriver) implements the interfaces and classes of the JDBC API. These standard sets of JDBC APIs enable developers to incorporate database services into their applications and ensure little or no change to the Java data-access code in the event your organization changes its database vendor. Figure 9.10. Connectivity to databases using WebLogic Server.  JDBC connections and access to a database can be initiated from the presentation or business layer of WebLogic Server by using JSP, servlets, session beans, or entity beans. However, if your application uses the Model-View-Controller (MVC) design model, you use entity beans to access your database by using one of the following persistence services: -
Bean-Managed Persistence (BMP) ” Enables you to manually control your database access by using the JDBC APIs. -
Container-Managed Persistence (CMP) ” Enables WebLogic Server to generate the required JDBC code automatically at runtime to access a database, synchronizing the beans' instance fields with the data in the database. The benefits of accessing a database by using WebLogic Server are as follows : -
WebLogic Server is fully JDBC 2.0 compliant. -
WebLogic Server provides a highly efficient RMI driver with row-level caching, which can be used with client- or server-side applications. -
Obtaining an initial connection to any database as well as managing the number of established connections can be time- intensive operations. To eliminate these concerns, WebLogic Server can configure connection pools that provide ready-to-use pools of connections to your database. By using connection pooling, WebLogic Server establishes a specified number of connections to your database upon startup. Client- and server-side applications can utilize these connections from a connection pool through a data source on the JNDI tree (the preferred method) or by using a multitier WebLogic driver. When the connection is no longer required, WebLogic Server returns the connection to the pool for another application to use. In addition, connection pools can be used in the context of a WebLogic Server cluster to provide high availability for database connections. -
For single-server configurations, WebLogic Server can use MultiPools, which are groups of connection pools that you can set by using one of the following algorithms: When an application requests a connection, the MultiPool determines which connection pool will provide a connection according to the selected algorithm. -
You can bind a JDBC data source resource into a WebLogic server's JNDI tree as a resource factory . Using resource factories enables you to map a resource factory reference in an EJB's deployment descriptor to an available resource factory in a running WebLogic server, which can then be used to obtain a database connection from a connection pool. -
You can set up connection pools, DataSources, Tx DataSources, and MultiPools as well as monitor established database connections through the Web-based Administration Console. Note A Tx DataSource refers to a DataSource that participates in local or distributed transactions.
J2EE Connector Architecture The J2EE Connector Architecture (J2CA) enables J2EE components, such as EJBs, to interact with EISs through resource adapters . A resource adapter is a J2EE component that implements the J2CA for a specific EIS, and enables a J2EE application and an EIS to communicate with each other. A resource adapter is analogous to a JDBC driver because they both provide a standard API through which a J2EE application can access a resource outside the application server. WebLogic Server has a built-in J2CA architecture that is fully compliant with the J2CA 1.0 specification. Resource adapters built on the J2CA 1.0 specification plug into WebLogic Server, as illustrated in Figure 9.11, and provide the underlying integration between an EIS and WebLogic Server through the following contracts and interfaces: Figure 9.11. WebLogic Server's J2EE Connector Architecture.  -
Application contract ” Defines the standard API through which a J2EE component accesses the EIS. This API is the only view that the component has of the EIS. -
System contract ” Links the resource adapter to important services the application server provides, such as connections, transactions, and security. -
Common client interface (CCI) ” Connects any EIS to an application server. Using the J2CA eliminates the need for EIS vendors to customize their products for each application server or integration framework. By conforming to the J2CA, WebLogic Server does not require additional custom code to extend its support connectivity to an EIS. WebLogic Server also provides a number of useful features to ease J2CA programming, such as -
Automatic pooling and reuse of connections to existing systems -
Integrated security, which enables a user to perform a single sign-on to a J2EE application and allows credentials to be automatically propagated to existing systems -
Transaction integration between WebLogic Server and EIS, enabling a J2EE application to involve existing systems in a larger Two-Phase Commit (2PC) transaction Interoperability with Microsoft Software Components To ensure bidirectional interoperability between J2EE components deployed in WebLogic Server and Microsoft's COM+ distributed component architecture, WebLogic Server provides a software bridge known as the WebLogic jCOM (or simply jCOM), as illustrated in Figure 9.12. Figure 9.12. Interoperability between Microsoft COM/DCOM and J2EE components using jCOM.  jCOM is a separate runtime component bundled with WebLogic Server, which implements both COM/DCOM over Distributed Computing Environment (DCE) Remote Procedure Call (RPC) and Remote Method Invocation (RMI) over RMI/IIOP distributed components' infrastructures . As illustrated in Figure 9.12, jCOM automatically builds the COM/DCOM proxies and RMI stubs between the two types of interfaces (WebLogic Server and COM/DCOM) and performs the necessary translation, which enables With jCOM, applications deployed on WebLogic Server can access data in Microsoft applications, such as Excel and Microsoft Word, as well as communicate with Visual Basic clients. BEA Tuxedo Interoperability BEA Tuxedo enables developers to develop, manage, and deploy C/C++ or COBOL applications based on procedural, CORBA, and Application-to-Transaction Monitor Interface (ATMI) programming models. WebLogic Server provides interoperability between WebLogic Server applications and Tuxedo services through the BEA WebLogic/Tuxedo Connector (WTC), as illustrated in Figure 9.13. Figure 9.13. The WebLogic/Tuxedo Connector.  The WebLogic/Tuxedo Connector is a built-in component of WebLogic Server and provides bidirectional interoperability with BEA Tuxedo, complete with transaction and security integration. Enterprise Messaging WebLogic Server includes a flexible and tightly integrated messaging infrastructure called the JMS Server, which implements the Java Messaging Service 1.0.2b API specification. The JMS Server is responsible for receiving messages and distributing them; it also supports the point-to-point (PTP) and publish/subscribe approaches to messaging. The major components of the WebLogic JMS Server architecture, illustrated in Figure 9.14, include the following: Figure 9.14. The WebLogic JMS Server architecture.  -
Messages ” The objects that communicate information between JMS clients. -
Destination ” An object that a JMS client uses to specify the target of messages it produces and the source of messages it consumes. In the PTP messaging domain, destinations are called queues , and in the publish/subscribe messaging domain, destinations are called topics . -
JMS Producers and JMS Consumers ” JMS clients are applications or components that produce or consume messages to and from a JMS queue or topic, respectively. Any J2EE component can act as a JMS client. -
Connection Factory ” An object that encapsulates connection configuration information and enables JMS clients to create an open communication channel (connection) with the messaging system. -
Java Naming and Directory Interface (JNDI) ” Destination and connection factories are bound to a JNDI API namespace, which allows JMS clients to perform a JNDI API lookup of connection factories and their destinations. -
Persistent storage ” Either a file or database for storing persistent message data. To provide a reliable, scalable, and high-performance enterprise messaging solution for communicating between asynchronous and heterogeneous resources, WebLogic Server's implementation of the JMS API includes the following features and enhancements: -
A single, unified messaging API exists throughout the WebLogic Platform infrastructure. -
Messaging support for applications spans different operating systems and machine architectures. -
WebLogic Server's JMS subsystem can be configured from the Web-based Administration Console or by using the JMS API to override values. -
WebLogic Server allows interoperability between JMS applications and other resource managers (primarily databases) by using Java Transaction API (JTA) transactions, which include support for distributed transactions and the 2PC protocol. JMS applications can also participate in transactions with other Java APIs that use JTA, including non-WebLogic XA “compliant message brokers . -
Messages that contain XML are fully supported. -
Using the Flow Control feature, you can enable a JMS server or destination to slow down message producers when it determines that it is becoming overloaded. -
Message multicasting allows the delivery of messages to a select group of hosts by using an IP multicast address. -
A database or a file can be used for persistent message storage. -
JMS can be used with other WebLogic Server APIs and facilities, such as EJBs, JDBC connection pools, servlets, and RMI. -
The WebLogic JMS architecture implements the clustering of multiple JMS servers, which provides the following advantages: -
Load-balancing destinations across multiple servers in the cluster. -
Clusterwide and transparent access to distributed destinations from any server in the cluster. -
Multiple physical destinations that can be configured as members of a single distributed destination set within a WebLogic cluster. Therefore, if one instance within the cluster fails, other instances of the same destination can provide service to JMS Producers and Consumers. -
Migratability, which allows WebLogic JMS to properly respond to migration requests and bring a JMS server online and offline in an orderly fashion. However, JMS topics and queues are still managed by individual WebLogic Server instances in the cluster. -
The WebLogic Server Messaging Bridge, also known as the JMS Bridge, enables you to configure a store-and-forward mechanism between any two messaging providers. This configuration provides interoperability between separate implementations of WebLogic JMS or between WebLogic JMS and another messaging product, such as MQSeries from IBM. -
The Message Paging feature can free virtual memory during peak message load periods by swapping out messages from virtual memory to persistent storage when message loads reach a specified threshold. Web Services Conceptually, a Web service is a self-contained (modular), self-describing , loosely coupled programmable component that can be exposed as a service-oriented system on a network and invoked across the Web (intranet, extranet, or Internet). Web services provide a platform-independent, standards-based means for achieving asynchronous access to applications in a heterogeneous distributed environment. They enable organizations to strengthen their value propositions by revealing their core competencies through a suite of interoperable software solutions, which can exist internally or externally to the enterprise through B2B integration, business-to-consumer (B2C) integration, or Enterprise Application Integration (EAI). To facilitate this model for connectivity and interoperability, WebLogic Web services use the XML-based SOAP 1.1 and 1.2 for the exchange of information in a loosely coupled and distributed environment. Web services deployed to WebLogic Server are described with WSDL 1.1 and can be registered with a public or private service registry by using the UDDI 2.0 standard. WebLogic Server's implementation of Web services supports all these standards, as illustrated in Figure 9.15. Figure 9.15. Web services support provided by WebLogic Server.  Also, in WebLogic Server 7, the Web services container has been enhanced to provide additional flexibility and to ensure interoperability with other key Web service vendors, such as Microsoft .NET. WebLogic Web services can be implemented by using the following technology components: -
Stateless session beans ” These beans, as illustrated in Figure 9.16, provide an RPC-style Web service that results in component operation invocations. SOAP messages contain parameters and return values. Figure 9.16. RPC-style Web services using stateless session beans.  -
Message-driven beans ” These beans, as illustrated in Figure 9.17, provide asynchronous processing and can be implemented as a JMS consumer, providing a document-oriented Web service. SOAP messages contain documents. Figure 9.17. Message-style Web services using message-driven beans as JMS consumers.  Note The Web services deployment descriptor ( web-services .xml ) can be used to pick and choose methods from one or more EJBs to expose within a single Web service. This provides greater flexibility and a looser coupling between back-end logic and the interface that is exposed.
-
SOAP message handler ” This message handler can be used to intercept a SOAP message in both the request and response of the Web service, enabling direct access to the entire SOAP 1.1 message (headers and attachments). The SOAP handler enables you to implement pre-processing and post-processing of SOAP requests, as illustrated in Figure 9.18. Figure 9.18. Pre-processing and post-processing of SOAP requests using message handlers.  -
Serializers and deserializers ” These components convert data between XML representation and Java objects. Because a Web service implementation is written in Java, mapping XML parameters to Java objects is a critical aspect of the Web services container. WebLogic Server provides built-in support for simple Java types that can be directly mapped into SOAP-specified types, as defined in the JAX-RPC specification. For applications that use more complex or user-defined types, the WebLogic Autotyper utility can be used to generate serializer and deserializer classes, as illustrated in Figure 9.19, that handle the conversion at runtime. As input, the WebLogic Autotyper utility accepts XML (or Java) representation of the types and generates the equivalent Java (or XML) representation along with the serializer and deserializer classes. Figure 9.19. Using serializers and deserializers for converting data types.  In general, the programming model for Web services in WebLogic Server is to leverage J2EE components and expose them as Web services. This approach allows Web services to be built on top of the J2EE support already provided by WebLogic Server, which enables deployed Web services to leverage the infrastructure services provided by WebLogic Server, such as transaction management, security, performance, and reliability. Additional WebLogic Server support for Web services includes -
Connection-oriented point-to-point security for WebLogic Web service operations as well as authorization and authentication of Web service operations. -
A ServiceGen Ant task that can automate the steps required to package and deploy Web services as an Enterprise Application Archive (EAR) file to WebLogic Server, as illustrated in Figure 9.20. All deployed WebLogic Web services automatically have a home Web page that includes links to the WSDL of the Web service, the client JAR file that you can download for invoking the Web service, and a mechanism for testing the Web service to ensure that it is working as expected. Note WebLogic Web services implement the Java APIs for XML-based RPC (JAX-RPC) as part of a client JAR that client applications can use to invoke WebLogic and non-WebLogic Web services.
Figure 9.20. The ServiceGen Ant task.  -
A built-in independent UDDI 2.0 registry that can be used to publish your Web services; you can use it in testing your Web service deployments. WebLogic Server can also leverage third-party UDDI registries. -
A Web Services Explorer tool, which you can use to search and discover available Web services by querying any UDDI registry. -
A new pull parser, which improves the performance of Web services applications by enabling developers to target specific portions of an XML document and avoid the need to parse the entire document, as is the case with SAX and DOM parsers. Interoperability with Mainframes Legacy applications that still reside on the mainframe do so because they are deemed mission critical, and the problems associated with maintenance are considered minor when you consider the real-time performance and solid reliability that the mainframe environment delivers. With today's fast-paced software development requirements, it is very unlikely you will be involved with developing enterprise applications for the mainframe. However, there is a greater possibility that the business transactions of your J2EE applications will require real-time direct integration with existing mainframe legacy applications. To meet the rigorous demands for fast and flawless mainframe integration, BEA provides the WebLogic Java Adapter for Mainframe (WebLogic JAM), which is a separate product that enables bidirectional, request-response integration between J2EE applications deployed on WebLogic Server and mainframe applications. As illustrated in Figure 9.21, bidirectional communication between WebLogic-hosted J2EE applications and mainframe applications is achieved through the following WebLogic JAM components: Figure 9.21. J2EE application and mainframe interoperability enabled using the WebLogic JAM product.  -
WebLogic JAM Gateway component ” This Java application runs in an instance of WebLogic Server and acts as a gateway to route requests and responses between WebLogic Server and the Communications Resource Manager (CRM). All gateway communications with the CRM use the TCP/IP protocol. -
Communications Resource Manager (CRM) ” This component runs on the mainframe and coordinates the flow of data between J2EE applications and mainframe applications. The CRM uses the SNA and TCP/IP communication protocols to communicate with the mainframe and WebLogic JAM Gateway, respectively. Additional technology features of the WebLogic JAM product include the following: -
An easy-to-use Web-based Administration Console enables you to configure and administer WebLogic JAM, which is an extension of WebLogic Server's Administration Console. -
Support is provided for distributed transactions by using the 2PC protocol. -
You can generate J2EE EJBs, servlets, or standalone Java clients from COBOL data structure definitions by using the eGen Application Generator development tool. -
Data translation is supported between Java, XML, and COBOL mainframe data types, and full Extended Binary Coded Decimal Interchange Code (EBCDIC) conversion is supported as well. Note EBCDIC is a character encoding set used by IBM mainframes.
-
Support is provided for using mainframe security credentials. -
Multiple instances of WebLogic JAM can be configured in a WebLogic cluster, providing load-balancing and failover of the integration services provided by WebLogic JAM. -
WebLogic JAM seamlessly plugs into WebLogic Integration, enabling mainframe interaction to incorporate advanced process rules and workflow.  |
