Oracle Corporation Web Server Convergence WebLogic Training Sitemap| Oracle Training Sitemap

Submit WebLogic Questions Knowledge Transfer WebLogic Schedule Definition of Service Delivery Medium Web Server Software

Oracle Web Servers WebLogic and Oracle Application Server

Operational Challenge JRocket in WebLogic Server WebLogic Platform and REST Qualifying a Training Request Client-specific Examples and Exercises Best Practices and Guidelines

Copyright Acknowledgement

Operational Challenge 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. How the foundation of open source standards that WebLogic Application Server is based are different than the commercial PL/SQL used in developing Oracle Application Server. Examining and analyzing whether organization's with a substantial investment in Oracle software, should deploy now, migrate later, or wait for new software to come to market. Identifying the technical issues associated with implementing either the WLS or Oracle Application Server. Developing the technical skills required to design and code applications using tools with a variety of programming languages. 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: High-performance JVM for server applications. Optimization and integration with Oracle Fusion middleware. Monitor and profile in-production application performance. Adaptive optimization in JRockit detects and addresses bottlenecks in a running program. 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. WebLogic Platform and REST 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. Addressability Identifies all resources using a URI. Uniform interface Enables the access of a resource using a uniform interface, such as HTTP methods: GET, POST, PUT, and DELETE. Stateless interaction Uses a stateless communication protocol, such as HTTP: Hypertext Transport Protocol. Layered system Enables client connection to an intermediary server rather than directly to the end server.   Qualifying a Training Request 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. Client-specific Examples and Exercises 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: Sending a request from a BPEL process and not waiting for an immediate response. Performing non-blocking calls using a parallel activity. Ensuring delivery using messaging. Implementing a publish/subscribe pattern. Handling events from a BPEL process. Oracle product changes relating to migration. Best Practices and Guidelines 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: 1. Create a custom store on each WebLogic Server that will host a JMS server. If there already is a custom store on a WebLogic Server, it typically will be more efficient for services to share a store. A custom store will provide additional flexibility in tuning and administration; it also is migratable. The default file store is not migratable. 2. In a cluster, target each store to its host server's default migratable target. If the decision has been made not to use a cluster, target each store directly to its host server. The recommended practice is to use migratable targets in place of direct server targets. Migratable targets are compatible with the Automatic Whole Server Migration option, and should be configured even when whole server migration is the primary fail-over option. 3. Configure a JMS server on each WebLogic Server and reference the store that was created in step 1. Target the JMS server to the same target that was used for the store; multiple JMS servers can reference the same store. 4. There is no default quota, configuration affords protection against out-of-memory conditions. Assume that each message consumes 512 bytes of memory. 5. Although JMS paging is enabled by default, verify that the default behavior is valid for the environment. Copyright Acknowledgement 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.