Oracle Corporation has been acquiring technologies and increasing targeted software and hardware market share. This has resulted in significant changes to the Oracle product line. With the acquisition of BEA Systems, WLS: WebLogic Server has been rebranded as Oracle WebLogic Application Server. Oracle's stated strategy is to make WebLogic Server its preferred application server. Complementary components from Oracle Application Server along with WebLogic Operations Control from BEA and Coherence from Tangosol have been integrated into WebLogic Server. Tangosol Coherence Grid is an enabler for the use of XTP: Extreme Transaction Processing in financial services, telecommunications, travel, and logistics industries.
During the convergence of functionality with the WebLogic Server, the challenge for Oracle customers will be managing different application server environments and then migrating to a standardized platform. In the interim, Oracle will be providing maintenance for current Oracle Application Server 10g customers.
This information has been incorporated into SYS-ED WebLogic courses and Oracle training programs.
JRocket in WebLogic Server
The JVM: Java Virtual Machine is used for implementing Java hardware and operating system independence. It is a foundation component of enterprise Java applications. There are significant differences among the versions. Oracle JRockit Real Time incorporates a number of advantages in real-time systems, application debugging, and memory leak control.
The JRocket facilities utilized in web servers and Java applications include:
Deterministic garbage collection is a memory management technique which minimizes transaction latency. Objects in Java that are no longer referenced must be periodically removed in order that processing can continue. The deterministic garbage collection capabilities in Oracle JRockit Real Time even out and deliver efficient reliable performance.
The REST: Representational State Transfer is an architectural style which provides a set of design rules for creating stateless services that are viewed as resources or sources of specific information data and functionality. It is a simple interface which transmits data over a standardized interface without an additional messaging layer. Each resource can be identified by its unique URI: Uniform Resource Identifier.
There is a Java API for RESTful web services and application development.
For an application to be RESTful, there are constraints defined by the REST architectural style which require adherence.
The client is looking at adopting SOA: Service Oriented Architecture at two separate levels.
1. The internal services require exposure to consumers as web services.
2. The internal architecture requires conversion for use in BPEL: Business Process Execution Language and web services.
The current architecture has been built upon a legacy mainframe infrastructure and there may be technical issues which need to be identified and addressed prior to conversion to SOA. SYS-ED will examine the software environment and provide an independent opinion on the degree of SOA that can be adopted.
Some of the services will need to be exposed as WSRP: Web Services for Remote Portlets. This essentially will offer the GUI front end for the services. This way, the consumer does not have to develop a front end application. The existing internal architecture uses a pub-sub style interaction instead of a request response type interaction. The training will provide guidance on whether this can be modeled using BPEL.
The examples and machine exercises will teach messaging and asynchronous communication:
The Java Messaging Service allows the sending and receiving of messages between clients. Configure JMS servers and persistent stores to create a custom store on each WebLogic Server hosting a JMS server. Custom stores provide flexibility in tuning and administration; the default file store is not migratable. Create and use custom connection factories instead of default connection factories. Default connection factories can not be tuned. There are issues which need to be evaluated prior to configuring JMS servers and persistent stores.
Destinations, connection factories, and other JMS resources are configured separately from their host JMS servers and persistent stores. When the strategy is to leverage WebLogic distributed destinations, it will be necessary to configure each WebLogic Server within a cluster with a JMS server and a custom persistent store. A JMS server can host non-distributed destinations or a set of similarly configured JMS servers each hosting the same distributed destination. There can be a single associated subdeployment for each set of JMS servers.
Migratable targets only are supported with clusters. When a cluster is not being used, the general recommendation is to reevaluate that decision and utilize a cluster of size one. This will enable the use of migratable targets for a restart-in-place capability. It also simplifies future modification of an application by expanding from a single to multiple servers.
To configure JMS servers and persistent stores:
Oracle Application Server and WebLogic Server are registered marks of Oracle Corporation.
Java is a registered trademark of Sun Microsystems, Inc. and Oracle America, Inc.