Monday, August 25, 2008

Oracle WebLogic Server 10g R3 Summary [WLS 10.3]

Introduction
Since the acquisition of BEA, Oracle releases BEA's WLS for the first time under the new brand Oracle WebLogic Server. Besides the new technical features discussed in this article, also notice the slightly modified name of the product from "10.3" to "10g R3". The codename of this release remained unchanged: ESSEX.
You can download it from this page.
Under Developer Tools at the bottom of the page, you can download the bundle WLS + Workshop 10.3 (even though the .exe file for Windows is still called server103_win32.exe, nothing about bundle or platform).

New Features

Admin Console
  • On-Demand Deployment:
    So far, internal
    applications like the WebLogic Administration Console, the UDDI and its explorer web app have been deployed at startup time (WLS 10.0).
    Now you can specify that such internal applications are only loaded at first access (on demand).
  • Console Configuration Search:
    You can now search for configuration values across the whole WebLogic Domain.
  • Security:
    Now supports SAML2
  • Spring Console:
    The WebLogic Console has been extended to inspect Spring Beans and manage them. As this feature is bundled as Console Extension, you need to enable it first via the preferences tab in the console (spring-console.jar) or you put the JAR file into the autodeploy folder $BEA_HOME\wlserver_10.3\server\lib\console-ext\autodeploy.
  • Guardian:
    Is now included in the WLS but disabled by default. Enable it via Domain Structure (left menu) and then Oracle Guardian Agent (to the right side)
Core Server
  • JDK 1.6 Support:
    A performance boost of about 10% can be expected compared to JDK 1.5 (which is still supported with this release but not recommended as primary choice)
  • Scripting Support:
    Web container supports multiple scripting languages, such as PHP, Groovy, and Ruby. For more information, see JSR 223: Scripting for the Java Platform.
  • Lightweight Server Runtime:
    WLS 10.3 provides two different runtime configurations: WLS or WLX.
    They are select via JAVA_OPTION -DserverType=“wlx” or "wls".
    BEA announced the "micro Service Architecture ( mSA ) " at BEA World 2006 and it seems that it took 'til now to really bring that architecture approach into their products.
    The default mode is WLS which loads all services internally. If WLX is selected, EJB, JMS and JCA is NOT loaded which results in a much smaller memory footprint as well as some performance boost at startup time.
  • FastSwap:
    The reloading of classes by class loaders (hot swapping, hot loading, hot classloading, hot deployment, etc.) without the need of a full web application redeployment is still not fully solved to satisfy today's developer needs that very often complain about the time wasted waiting for a redeployment.
    While JDK 1.5 brought the hotloading feature already but with certain limitations (works as long as class variables and method signatures have not changed), WLS 10.3 eliminates those to a certain extent:

    Limitations: The following changes are not supported by FastSwap:
    - Changing the list of implemented interfaces or the superclass
    - Changes to the class' annotations (as this is solved via Reflection)
    - Changes of EJB interface methods
    - Changes of Enum based constants
    - Addition or Removal of a finalize method
    - Only available in "Development Mode"
    - In general all Java Reflection based features are not supported by FastSwap (there is a commercial product available that does not have this limitation: Java Rebel 1.0 (might be aquired by Oracle soon ;-)

    Said in a nutshell how FastSwap works:
    If enabled via weblogic-application.xml (configure the item true), there is a agent running in the JVM for each deployed web app which scans the following directories for new classfiles (based on the timestamps):

    earApp/APP-INF/classes
    earApp/webapp/WEB-INF/classes

  • Additional to the EJB3 annotations, the following are supported when Kodo is used as Persistence Provider:

Annotation
Description
@AllowRemoveDuringTransaction
Flag that specifies an instance can be removed during a transaction.
@CallByReference
Flag that specifies the parameters are passed by reference.
@DisableWarnings
Flag that specifies all warning messages are disabled.
@Idempotent
Number of times you want the EJB container to automatically retry a container-managed transaction method that has rolled back.
@JMSClientID
Client ID for the MDB when it connects to a JMS destination. Required for durable subscriptions to JMS topics.
@JNDIName
JNDI name of an actual EJB, resource, or reference available in WebLogic Server.
@MessageDestinationConfiguration
JNDI name of the JMS Connection Factory that a message-driven EJB looks up to create its queues and topics.
@TransactionIsolation
Method-level transaction isolation settings for an EJB.
@TransactionTimeoutSeconds
Timeout for transactions in seconds.

Application Development
  • Spring Security:
    The Spring security (acegi) provides security to a Spring application while providing a rich set of security providers.
    In order to combine JAAS based security providers with your Spring Security features, you can use any authentication provider for performing authentication.
    After successful authentication, WLS principals are converted to Spring GrantedAuthority through a mapper class. After than, Spring Security is performing the authorization phase.

  • Comet, Bayeux Protocol, HTTP Publish Subscribe Server:

    Overview

    Since 10.3, developers of Web 2.0 applications can take advantage of this new feature:
    The HTTP Publish-Subscribe Server allows clients to subscribe to a channel (similar to a topic in JMS) and receive messages as they become available. Behind the scenes, the Bayeux Protocol is used which defines a contract between the client and the server for communicating with asynchronous messages over HTTP. The server-side push technology is called Comet.

    How to use
    Each web application has its own instance of a pub-sub-server so the configuration is on web app level: the web app's weblogic.xml descriptor references the shared Java EE Library of the pub-sub-server and enables it that way. Once enabled, the configuration is done in the weblogic-pubsub.xml.

    Web application developers can optionally use server-side pub-sub APIs in their servlets or Java classes to get the pub-sub server context, manage channels, and manage the incoming and outgoing messages to and from the clients.
    If Ajax clients need to interact with the WebLogic based web application via the pub-sub-server, WLS 10.3 provides a Dojo based java script library that support two out of four transport types: long-polling and callback-polling.

    Scalability:
    Horizontal scalability is solved by clustering. Pub-Sub-Servers are per default using in-memory persistence, are kind of clusterable but isolated. This means that each runs in its own context and is not aware of others (e.g. a chat application does not broadcast the message to all members in the cluster).
    But WLS 10.3 allows you to configure JMS to be the persistence message provider for the pub-sub-server. Configuration details and limitations are documented in the official documentation.

Supported Frameworks
  • Spring 2.0.2
Supported Databases
  • MySQL 5.x
  • Oracle 9,10,11 and Oracle RAC 10g and 11g
  • Pointbase 5.6
  • Sybase 12.5.03 and 15
  • Microsoft SQL Server 2005

Java Standard
Version
Java EE
5.0
JDKs
1.6 and 1.5 (1.6 is 15% faster)
Java EE Enterprise Web Services
1.2, 1.1
Web Services Metadata for the Java Platform
2.0, 1.1
Java API for XML-Based Web Services (JAX-WS)
2.1, 2.0
Java EE EJB
3.0, 2.1, 2.0, and 1.1
Java EE JMS
1.1, 1.0.2b
Java EE JDBC (with third-party drivers)
4.0, 3.0
MS SQL jDriver
1.0
Oracle OCI jDriver
1.0 and some 2.0 features (batching)
Java EE JNDI
1.2
OTS/JTA
1.2 and 1.1
Java EE Servlet
2.5, 2.4, 2.3, and 2.2
Java EE Application Deployment
1.2
Java Authorization Contract for Containers (JACC)
1.1
Java EE JSP
2.1, 2.0, 1.2, and 1.1
RMI/IIOP
1.0
JMX
1.2, 1.0
JavaMail
1.2
JAAS
1.0 Full
Java EE CA
1.5, 1.0
Java EE JSF
1.2, 1.1
Java EE JSTL
1.2, 1.1
JCE
1.4
Java RMI
1.0
JAX-B
2.1, 2.0
JAX-P
1.2, 1.1
JAX-RPC
1.1, 1.0
JAX-R
1.0
SOAP Attachments for Java (SAAJ)
1.3, 1.2
Streaming API for XML (StAX)
1.0
JSR 77: Java EE Management
1.1
JSR 233: Java EE Management
JSR 223: Scripting in the Web Container: PHP, Ruby
1.1
1.0

Web Service Standard
Version
Java EE Web Services
1.2, 1.1
Web Services Metadata for the Java Platform (JWS)
2.0, 1.0
Java API for XML-Based Web Services (JAX-WS)
2.1
SOAP
1.1, 1.2
WSDL
1.1
JAX-RPC
1.1
SOAP Attachments for Java (SAAJ)
1.3, 1.2
WS-Security
1.1, 1.0
WS-Policy
1.2, 1.5
WS-SecurityPolicy
1.2
WS-PolicyAttachment
1.0
WS-Addressing
1.0, 2004/08 member submission
WS-ReliableMessaging
1.1, 1.0
WS-Trust
1.3
WS-SecureConversation
1.3
UDDI
2.0
JAX-R
1.0
JAX-B
2.1, 2.0
SAML
2.0
SAML Token Profile
1.1


Other Standard
Version
SSL
v3
X.509
v3
LDAP
v3
TLS
v1
HTTP
1.1
SNMP
SNMPv1, SNMPv2, SNMPv3
xTensible Access Control Markup Language (XACML)
2.0
Partial implementation of Core and Hierarchical Role Based Access Control (RBAC) Profile of XACML
2.0
SAML
1.1, 2.0
Data Direct database drivers
3.7

1 comment:

sync said...

Thanks for well written summary on WLS 10.3.

In the article, it mentioned it could be downgraded to use JDK 1.5, minus the performance gain.

Is this done through the per domain setup which we could select the JDK to use? Is there any other issue that should be noted other than performance when using JDK 1.5?

Is it even possible to specify JDK version per web application deployed on WLS 10.3?


Thanks.