Weblogic Remote Deploy from Red Hat Enterprise Linux Server: Unknown object in LOCATE_REQUEST

Recently I was attempting to deploy to weblogic from a Jenkins installed on a Red Hat Enterprise Linux Server release 7.3, to a remote Weblogic 12.1.3 cluster. Which was failing with a org.omg.CORBA.OBJECT_NOT_EXIST. Eventually, I ended up trying to do a manual deploy using the ANT task wldeploy, with the following command

 ant -lib /apps/wls12130/wlserver/server/lib deploy -Dweblogic.user=adminuser -Dweblogic.password=adminpassword -Dadminurl=t3://admin-server:admin-port -Dweblogic.cluster=ClusterName

As you can see from the command, we are passing command-line arguments which specify the location and credentials for the remote cluster. On the Linux machine to with the [wldeploy] Caused by: javax.naming.NamingException: Couldn't connect to the specified host [Root exception is org.omg.CORBA.OBJECT_NOT_EXIST: Unknown object in LOCATE_REQUEST vmcid: 0x0 minor code: 0 completed: No] error. Following is the full stacktrace, followed by a cause and resolution to this problem...

Implementing JMS with Spring: Message Driven POJO

The previous post described how to implement a JMS messaging client using Spring JMS. This post will describe how to implement the Message listener as a spring Message driven POJO. Follow these steps to implement the Message driven POJO

1. Create the Message Driven POJO: The only requirement for the Message Driven POJO is to implement the MessageListener interface. The following listing shows the code for the MDP

   public class SpringMDP implements MessageListener {
   public void onMessage(Message message) {
    try {
      System.out.println(((TextMessage) message).getText());
    } catch (JMSException ex) {
      throw new RuntimeException(ex);
    }
   }
   }

   SpringMDP.java


2. Create the bean definition in applicationContext.xml file.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
   "http://www.springframework.org/dtd/spring-beans.dtd">
   <beans>
     <!-- this is the Message Driven POJO (MDP) -->
     <bean id="messageListener" class="jms.SpringMDP" />
   
   <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
    <property name="environment">
      <props>
        <prop key="java.naming.factory.initial">weblogic.jndi.WLInitialContextFactory</prop>
        <prop key="java.naming.provider.url">t3://localhost:20001</prop>
      </props>
    </property>
   </bean>
   <bean id="connectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiTemplate">
      <ref bean="jndiTemplate" />
    </property>
    <property name="jndiName">
      <value>jms/connectionFactory</value>
    </property>
   </bean>
   
   <bean id="queue" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiTemplate">
      <ref bean="jndiTemplate" />
    </property>
    <property name="jndiName">
      <value>jms/testQueue</value>
    </property>
   </bean>
   
   
     <bean id="listenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
       <property name="concurrentConsumers" value="5" />
       <property name="connectionFactory" ref="connectionFactory" />
       <property name="destination" ref="queue" />
       <property name="messageListener" ref="messageListener" />
     </bean>
   </beans>
   

   WEB-INF/applicationContext.xml
   The Message listener container handles all the required functions for making the Simple POJO a Message Driven POJO.


3. Update Web.xml to include a listener for spring.

   <listener>  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
   </listener>
   

Implementing JMS with Spring: Messaging Client

Last week, I described how to implement JMS, using a stand-alone client and a Message Driven Bean. In this post and the next, I will describe how to implement JMS using Spring and Message Driven POJOs. This post will describe how to create a Messaging client using Spring. The next post will describe how to implement a Message driven POJO. For this I used a simple servlet that, when invoked will send a text message "hello", to a destination queue. The Message driven pojo, listening on the queue will then receive and print the message. Follow these steps to run the example

1. Setup the JMS environment as described in the "Configuring Weblogic JMS" post
2. Create the Messaging client: This is a simple Java class which uses the spring JmsTemplate to send a message to the queue. The JmsTemplate can be used for message production and synchronous message reception. For asynchronous reception, Spring provides a number of message listener containers that are used to create Message-Driven POJOs (MDPs).

   public class QueueSender {
   private JmsTemplate jmsTemplate;
   public void setJmsTemplate(JmsTemplate jmsTemplate) {
   this.jmsTemplate = jmsTemplate;
   }
   public void sendMesage() {
   jmsTemplate.send("jms/testQueue", new MessageCreator() {
         public Message createMessage(Session session) throws JMSException {
           return session.createTextMessage("Hello");
         }
       });
   }
   }

   QueueSender.java
3. Configure the Bean in the applicationContext.xml file: The following is alisting of the applicationContext.xml file.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
   "http://www.springframework.org/dtd/spring-beans.dtd">
   <beans>
   <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
   <property name="environment">
    <props>
      <prop key="java.naming.factory.initial">weblogic.jndi.WLInitialContextFactory</prop>
      <prop key="java.naming.provider.url">t3://localhost:20001</prop>
    </props>
   </property>
   </bean>
   
   <bean id="queueConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
   <property name="jndiTemplate">
    <ref bean="jndiTemplate" />
   </property>
   <property name="jndiName">
    <value>jms/connectionFactory</value>
   </property>
   </bean>
   
   <bean id="jmsDestinationResolver" class="org.springframework.jms.support.destination.JndiDestinationResolver">
   <property name="jndiTemplate">
    <ref bean="jndiTemplate" />
   </property>
   <property name="cache">
    <value>true</value>
   </property>
   </bean>
   
   <bean id="queueTemplate" class="org.springframework.jms.core.JmsTemplate">
   <property name="connectionFactory">
    <ref bean="queueConnectionFactory" />
   </property>
   <property name="destinationResolver">
    <ref bean="jmsDestinationResolver" />
   </property>
   </bean>
   
   <bean id="jmsSender" class="jms.QueueSender">
   <property name="jmsTemplate">
    <ref bean="queueTemplate" />
   </property>
   
   </bean>
   </beans>

   WEB-INF/applicationContext.xml
   The JndiDestinationResolver class can be used to obtain the Queue destinations using the JNDI Name. The send method in JmsTemplate (see QueueSender), uses the JNDI name, which is used by the JndiDestinationResolver to obtain the appropriate destination.


4. Create a servlet to invoke the Message Sender: The following servlet is used to invoke the QueueSender:

    public class QueueSenderServlet extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet {
   protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
   WebApplicationContext ctx = WebApplicationContextUtils.getRequiredWebApplicationContext(this.getServletContext());
   QueueSender sender = (QueueSender)ctx.getBean("jmsSender");
   sender.sendMesage();
   }
   }

   QueueSenderServlet.java
5. Update the web.xml file to add the servlet and spring application context:

   <?xml version="1.0" encoding="UTF-8"?>
   <web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
   <display-name>SpringJMSClientWeb</display-name>
   <servlet>
   <description></description>
   <display-name>QueueSenderServlet</display-name>
   <servlet-name>QueueSenderServlet</servlet-name>
   <servlet-class>jms.QueueSenderServlet</servlet-class>
   </servlet>
   <servlet-mapping>
   <servlet-name>QueueSenderServlet</servlet-name>
   <url-pattern>/QueueSenderServlet</url-pattern>
   </servlet-mapping>
   <listener>
   <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
   </listener>
   </web-app>

   web.xml
   The listener defined web.xml (ContextLoaderListener) by default loads the applicationContext.xml file in WEB-INF directory of the web application.

In the next post, we will see how implement the Message Driven POJO to consume the message sent from here.

Basic web service implementation

This post describes how to implement a simple webservice using Weblogic, Eclipse, and Apache Axis. We will go through these steps to implement the Webservice

1. Enable Weblogic domain for WebServices
2. Create a simple web service class.
3. Auto-generate WebServices classes in Eclipse
4. Auto-generate the classes for calling the web service.
5. Create a Client Application

1. Enable Weblogic domain for WebServices: Follow these steps to enable your weblogic domain for web services.
   1. Start the Configuration Wizard (c:/bea9.2/weblogic92/common/bin/config.cmd)
   2. In the Welcome window, select Extend an Existing WebLogic Domain. Click Next.
   3. Select the domain to which you want to apply the extension template. Click Next.
   4. Select Extend My Domain Using an Existing Extension template.
   5. Enter the following value in the Template Location text box: WL_HOME/common/templates/applications/wls_webservice.jar. Click Next.
   6. Select no. Click next.
   7. Verify that you are extending the correct domain, then click Extend.
2. Create a simple web service class: Create an Eclipse Web Project. The reason for using a Web Project is that the J2EE specification requires that for implementing you need one of the following.
   • A Java class running in the Web container.
   • A stateless session EJB running in the EJB container.
   Create the following class within the web application.

   public class TestService {
   public String sayHello(String message) {
    System.out.println("sayHello:" + message);
    return "You said '" + message + "'";
   }
   }

   TestService.java
3. Auto-generate WebServices classes in Eclipse: Right-click on the TestService.java class and select Web Services->Create Web Service. If you have a weblogic server defined in eclipse, then the Web service will be automatically published to the server. Make sure that your server definition looks like this.


4. Auto-generate the classes for calling the web service: Create a Java application and copy the generated WSDL file from the web project. Right-click on the WSDL file and Web Services->Generate client. All the required classes will be generated, and the jar files will also be imported.
5. Create a Client Application: We will use a simple Java client for this web service. The following is the code for the client application.

   import java.rmi.RemoteException;
   import service.TestService;
   import service.TestServiceProxy;
   public class SimpleClient {
   public static void main(String[] args) {
    TestService service = new TestServiceProxy();
    try {
      System.out.println(service.sayHello("Hello"));
    } catch (RemoteException e) {
      e.printStackTrace();
    }
   }
   }

This example was run on Weblogic 9.2, Eclipse Callisto 3.2, Java 5.0.

Messaging Quickstart: Sample Code

The previous post described how to setup a Queue in Weblogic Server. This post shows the code necessary to run a Simple Messaging example using a servlet and Message Driven Bean. You can always implement an message listener instead of using a Message Driven Bean, but using MDBs is much cleaner and easier. Follow these steps to run the example

1. Setup XDoclet
   1. Download XDoclet from here, and extract it.
   2. In Eclipse->Window->preferences, select xdoclet and set the Xdoclet home to the appropriate directory.
2. Create the Message Driven Bean
   1. Create an EJB project in Eclipse.
   2. In the J2EE perspective, right-click on the Deployment descriptor and create a new Message Driven Bean. Eclipse generates the required classes and the ejb-jar.xml file with the new MDB definition in it. Modify the Bean to look like this

      public class MessagingExampleBean implements javax.ejb.MessageDrivenBean, javax.jms.MessageListener {
      private javax.ejb.MessageDrivenContext messageContext = null;
      public void setMessageDrivenContext(javax.ejb.MessageDrivenContext messageContext) throws javax.ejb.EJBException {
       this.messageContext = messageContext;
      }
      public void ejbCreate() {
      }
      public void ejbRemove() {
         messageContext = null;
      }
      public MessagingExampleBean() {
      }
      public void onMessage(javax.jms.Message message) {
       System.out.println("Message Driven Bean got message " + message);
      }
      }

      Add the following definitions to the ejb-jar.xml

      <?xml version="1.0" encoding="UTF-8"?>
      <ejb-jar version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
      <display-name>MessagingExample</display-name>
      <enterprise-beans>
       <message-driven>
         <display-name>MessagingExampleMDB</display-name>
         <ejb-name>MessagingExampleMDB</ejb-name>
         <ejb-class>jms.MessagingExampleMdb</ejb-class>
         <transaction-type>Bean</transaction-type>
         <message-destination-type>javax.jms.Queue</message-destination-type>
       </message-driven>
      </enterprise-beans>
      <assembly-descriptor>
       <container-transaction>
         <method>
           <ejb-name>MessagingExampleMDB</ejb-name>
           <method-name>*</method-name>
         </method>
         <trans-attribute>Required</trans-attribute>
       </container-transaction>
      </assembly-descriptor>
      </ejb-jar>

   3. Create a new file weblogic-ejb-jar.xml. This is required for Weblogic bindings.

      <?xml version="1.0" encoding="UTF-8"?>
      <!DOCTYPE weblogic-ejb-jar PUBLIC "-//BEA Systems, Inc.//DTD WebLogic 8.1.0 EJB//EN" "http://www.bea.com/servers/wls810/dtd/weblogic-ejb-jar.dtd">
      <weblogic-ejb-jar>
      <weblogic-enterprise-bean>
       <ejb-name>MessagingExampleMDB</ejb-name>
       <message-driven-descriptor>
         <pool>
           <max-beans-in-free-pool>5</max-beans-in-free-pool>
           <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
         </pool>
         <destination-jndi-name>jms/testQueue</destination-jndi-name>
         <initial-context-factory>weblogic.jndi.WLInitialContextFactory</initial-context-factory>
         <connection-factory-jndi-name>jms/connectionFactory</connection-factory-jndi-name>
         <jms-polling-interval-seconds>20</jms-polling-interval-seconds>
       </message-driven-descriptor>
       <transaction-descriptor>
         <trans-timeout-seconds>3600</trans-timeout-seconds>
       </transaction-descriptor>
      
      </weblogic-enterprise-bean>
      </weblogic-ejb-jar>

3. Create the Client. For this example, I used a servlet that simply sends a "Hello" message to the MDB through the Queue. Here is the code for it

   public class MessaginClientServlet extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet {
   public final static String JNDI_FACTORY = "weblogic.jndi.WLInitialContextFactory";
   public final static String JMS_FACTORY = "weblogic.examples.jms.QueueConnectionFactory";
   public final static String QUEUE = "weblogic.examples.jms.exampleQueue";
   public MessaginClientServlet() {
    super();
   }
   protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    try {
      Context ctx = getInitialContext("t3://localhost:20001");
      QueueConnectionFactory qconFactory;
      QueueConnection connection;
      QueueSession session;
      QueueSender sender;
      Queue queue;
      TextMessage msg;
   
      qconFactory = (QueueConnectionFactory) ctx.lookup("jms/connectionFactory");
      connection = qconFactory.createQueueConnection();
      session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
      queue = (Queue) ctx.lookup("jms/testQueue");
      msg = session.createTextMessage();
      sender = session.createSender(queue);
      msg.setText("Hello World");
      connection.start();
      sender.send(msg);
      session.close();
      connection.close();
    } catch (Exception e) {
      e.printStackTrace();
    }
   }
   
   private InitialContext getInitialContext(String url) throws NamingException {
    Hashtable<String, String> env = new Hashtable<String, String>();
    env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
    env.put(Context.PROVIDER_URL, url);
    return new InitialContext(env);
   }
   }

Messaging Quickstart: Configuring Weblogic JMS

This is a basic example of how to implement Messaging in Java using JMS and Message driven beans. The example is implemented using Weblogic JMS implementation. This part describes how to configure a queue on weblogic, the next part will describe the programming involved to run the example.Follow these steps to configure a queue in Weblogic:

1. Create a JMS Server
   1. In the admin console go to Home > Summary of Services: JMS > Summary of JMS Servers and click on Lock & Edit and then click on New.
   2. In the next screen choose a name and create a new File Store and click next.
   3. Select the deployment target and finish.
   
2. Create a JMS Module: Go to JMS Modules in the Admin console and create a new module, accept defaults.
3. Create a Connection Factory: Go to Home > JMS Modules > jmsModule. Select new and create a new connection factory. Set the JNDI name to jms/connectionFactory
4. Create a Destination: Go to Home > JMS Modules > jmsModule and Create a new Queue and set the JNDI name to jms/testQueue. When creating a queue, select "create a new Sub deployment" and create a new sub-deployment.

Go to part 2.

Configuring LDAP in Weblogic

WebLogic Server does not support or certify any particular LDAP servers. Any LDAP v2 or v3 compliant LDAP server should work with WebLogic Server. The LDAP Authentication providers in this release of WebLogic Server (v9.2) are configured to work readily with the SunONE (iPlanet), Active Directory, Open LDAP, and Novell NDS LDAP servers. You can use an LDAP Authentication provider to access other types of LDAP servers. Choose either the LDAP Authentication provider (LDAPAuthenticator) or the existing LDAP provider that most closely matches the new LDAP server and customize the existing configuration to match the directory schema and other attributes for your LDAP server. The server comes with the following Authentication Providers, which help to configure different LDAP servers

• iPlanet Authentication provider
• Active Directory Authentication provider
• Open LDAP Authentication provider
• Novell Authentication provider
• generic LDAP Authentication provider

Follow these steps to configure LDAP in Weblogic:

1. Choose an LDAP Authentication provider that matches your LDAP server and create an instance of the provider in your security realm.
   
2. Configure the provider-specific attributes of the LDAP Authentication provider, which you can do through the Administration Console. For each LDAP Authentication provider, there are attributes that:
   1. Enable communication between the LDAP server and the LDAP Authentication provider. For a more secure deployment, BEA recommends using the SSL protocol to protect communications between the LDAP server and WebLogic Server. Enable SSL with the SSLEnabled attribute.
   2. Configure options that control how the LDAP Authentication provider searches the LDAP directory.
   3. Specify where in the LDAP directory structure users are located.
   4. Specify where in the LDAP directory structure groups are located.
   5. Define how members of a group are located.
3. Configure performance options that control the cache for the LDAP server. Use the Configuration: Provider Specific and Performance pages for the provider in the Administration Console to configure the cache.
   

FAILOVER
You can configure an LDAP provider to work with multiple LDAP servers and enable failover if one LDAP server is not available. For this, Change the Host attribute in the security_realm > Providers > provider_specific page, to contain a list of hostnames and ports (localhost:389, remotehost:389). When using failover, the Parallel Connect Delay and Connection Timeout attributes have to be set for the LDAP Authentication provider:

• Parallel Connect Delay—Specifies the number of seconds to delay when making concurrent attempts to connect to multiple servers. An attempt is made to connect to the first server in the list. The next entry in the list is tried only if the attempt to connect to the current host fails. This setting might cause your application to block for an unacceptably long time if a host is down. If the value is greater than 0, another connection setup thread is started after the specified number of delay seconds has passed. If the value is 0, connection attempts are serialized.
• Connection Timeout—Specifies the maximum number of seconds to wait for the connection to the LDAP server to be established. If the set to 0, there is no maximum time limit and WebLogic Server waits until the TCP/IP layer times out to return a connection failure. Set to a value over 60 seconds depending upon the configuration of TCP/IP.

NOTE
If an LDAP Authentication provider is the only configured Authentication provider for a security realm, you must have the Admin role to boot WebLogic Server and use a user or group in the LDAP directory. You can either create an Administrators group in the LDAP directory, and include your user in that group, or use an existing group and add the group to the admin role in the WebLogic Administration Console. For more information refer to Weblogic documentation: Configuring LDAP providers.

Weblogic Security

WebLogic Security Framework provides a simplified application programming interface (API) that can be used by security and application developers to define security services. WebLogic Security Framework also acts as an intermediary between the WebLogic containers (Web and EJB), the Resource containers, and the security providers. In this post, I describe a few concepts and features available in Weblogic Server 9.2 for authentication and authorization and auditing.
Authentication
Authentication is the process of determining whether the client who it claims to be. Generally, authentication is accomplished by the client sending credentials (username/password, certificate, security token etc.) and the server verifying the credentials. WebLogic uses the authentication classes of the Java Authentication and Authorization Service (JAAS), for authentication.
Identity Assertion
Weblogic also supports the concept of perimeter-based authentication, where the actual authentication process occurs at an application perimeter such as a Web server, firewall, or VPN, and outside of WebLogic Server. The perimeter authentication provider then asserts the identity to the Weblogic server using different "Security token types" (e.g., Microsoft Passport, SAML Assertions, or tokens from third-party commercial authentication products). The "security tokens" are validated by the Weblogic Server, which then assigns a username to the token. This username is used by the authentication providers to populate the "Subject" that will be used in authorization. IBM WebSphere implements this by the use of Trust Association Interceptors. WebLogic Server 's support for perimeter-based authentication supports the ability to propagate security tokes over multiple protocols, such as HTTP, and IIOP-CSIv2 (used for EJB layer security).
Authorization
Authorization phase determines if the user has access to the requested application resource. Authorization in Weblogic is divided in to two steps

1. Decision
2. Adjudication (Enforce)
   

Decision
In this step, the WebLogic Security Framework uses the request parameters and user information to determine the roles associated with the user (for this the security framework uses the configured Role Mapping Providers). Based on the user's roles, the Authorization provider determines whether the subject is entitled to access the requested resource i.e the Authorization provider makes the Access Decision. If there are multiple Authorization providers configured, the WebLogic Security Framework delegates the job of reconciling any conflicts in the Access Decisions to the Adjudication provider
Adjudication
The Adjudication provider is required to tally the multiple Access Decisions and render a verdict. The Adjudication provider returns either a TRUE or FALSE verdict to the Authorization providers, which forward it to the resource container through the WebLogic Security Framework.

• If the decision is TRUE, the resource container dispatches the request to the protected WebLogic resource.
• If the decision is FALSE, the resource container throws a security exception that indicates that the requestor was not authorized to perform the requested access on the protected WebLogic resource.

Auditing
The auditing process is initiated when a resource container passes a user's authentication information to the WebLogic Security Framework as part of a login request. If, in addition to providing authentication services, the Authentication provider is designed to post audit events, the Authentication provider instantiates an AuditEvent object. The AuditEvent object includes information such as the event type and an audit severity level. The Authentication provider then calls the Auditor Service in the WebLogic Security Framework, passing in the AuditEvent object. The Auditor Service passes the AuditEvent object to the configured Auditing providers' runtime classes, enabling audit event recording. Depending on the Auditing provider implementation, audit records may be written to a file, a database, or some other persistent storage medium.

Weblogic: SSO with Windows

An increasing number of intranet-based applications are requiriong Single sign-on (SSO) with between Windows clients (web browser, .NET application etc.) and Java EE servers. The last time, I blogged SSO with IBM WebSphere application server and Windows. To implement this feature, the Microsoft clients must use Windows authentication based on the Simple and Protected Negotiate (SPNEGO) mechanism.

Cross-platform authentication is achieved by emulating the negotiate behavior of native Windows-to-Windows authentication services that use the Kerberos protocol. In order for cross-platform authentication to work, non-Windows servers (WebSphere/WebLogic Servers) need to parse SPNEGO tokens in order to extract Kerberos tokens which are then used for authentication. This post gives a brief overview of the requirements and steps to setup SSO with Windows in Weblogic and provides the resources for further reference:
Requirements
Server

• Windows 2000 or later installed
• Fully-configured Active Directory authentication service.
• WebLogic Server installed and configured properly to authenticate through Kerberos

Client

• Windows 2000 Professional SP2 or later installed
• One of the following types of clients:
  • A properly configured Internet Explorer browser. Internet Explorer 6.01 or later is supported.
  • .NET Framework 1.1 and a properly configured Web Service client.
• Clients must be logged on to a Windows 2000 domain and have Kerberos credentials acquired from the Active Directory server in the domain. Local logons will not work.

Main Steps for Congifuration
Configuring SSO with Microsoft clients requires set-up procedures in the Microsoft Active Directory, the client, and the WebLogic Server domain.

• Define a principal in Active Directory to represent the WebLogic Server. The Kerberos protocol uses the Active Directory server in the Microsoft domain to store the necessary security information.
• Any Microsoft client you want to access in the Microsoft domain must be set up to use Windows Integrated authentication, sending a Kerberos ticket when available.
• In the security realm of the WebLogic Server domain, configure a Negotiate Identity Assertion provider. The Web application or Web Service used in SSO needs to have authentication set in a specific manner. A JAAS login file that defines the location of the Kerberos identification for WebLogic Server must be created.

To configure SSO with Microsoft clients:

1. Configure your network domain to use Kerberos.
2. Create a Kerberos identification for WebLogic Server.
1. Create a user account in the Active Directory for the host on which WebLogic Server is running.
2. Create a Service Principal Name for this account.
3. Create a user mapping and keytab file for this account.
3. Choose a Microsoft client (either a Web Service or a browser) and configure it to use Windows Integrated authentication.
4. Set up the WebLogic Server domain to use Kerberos authentication.
1. Create a JAAS login file that points to the Active Directory server in the Microsoft domain and the keytab file created in Step 1.
2. Configure a Negotiate Identity Assertion provider in the WebLogic Server security realm.
5. Start WebLogic Server using specific start-up arguments.

References

• Weblogic Documentation: Configuring Single Sign-On with Microsoft Clients
• Weblogic Documentation: Weblogic Security Service Architecture
• SSO with SPNEGO (articles on appliedcrypto)

Weblogic Split Directory Environment

The WebLogic split development directory environment consists of a directory layout and associated Ant tasks that help you repeatedly build, change, and deploy J2EE applications. Using the split directory structure speeds-up the deployment time by avoiding unnecessary copying of files. In the split directory structure, the application directories are split into source and build directories.

• The source directory contains the Java source files, deployment descriptors, JSPs etc. along with static content.
• The build directory contains files generated during the build process.

The source directory is organized as follows:

root (represents the ear)
|_ EJB Modules/web modules
|_ Application Deployment descriptor (application.xml)
|_ Shared utility classes
|_ Common libraries shared by the different modules.

The split development directory structure requires each project to be staged as a J2EE Enterprise Application. BEA recommends that you stage even stand-alone Web applications and EJBs as modules of an Enterprise application, to benefit from the split directory Ant tasks.

Deploying from a Split Development Directory
All WebLogic Server deployment tools (weblogic.Deployer, wldeploy, and the Admin Console) support direct deployment from a split development directory. When an application is deployed to WebLogic Server, the server attempts to use all classes and resources available in the source directory for deploying the application. The server looks in the build directory only for the resources not available in the source directory.

Ant Tasks
The following is a list of Ant tasks that help you deploy applications using the split development directory environment.

• wlcompile—This Ant task compiles the contents of the source directory into subdirectories of the build directory.
• wlappc—Used to generate JSPs and container-specific EJB classes for deployment.
• wldeploy—Deploys any format of J2EE applications (exploded or archived) to WebLogic Server. To deploy directly from the split development directory environment, you specify the build directory of your application.
• wlpackage—Used to generate an EAR file or exploded EAR directory from the source and build directories.

After you set up your source directory structure, use the weblogic.BuildXMLGen utility to create a basic build.xml file. The syntax for weblogic.BuildXMLGen is as follows:

java weblogic.BuildXMLGen [options] 

After running weblogic.BuildXMLGen, edit the generated build.xml file to specify properties for your development environment.

Summary
The following steps illustrate how you use the split development directory structure to build and deploy a WebLogic Server application.

1. Create the main EAR source directory for your project. When using the split development directory environment, you must develop Web Applications and EJBs as part of an Enterprise Application, even if you do not intend to develop multiple J2EE modules.
2. Add one or more subdirectories to the EAR directory for storing the source for Web Applications, EJB components, or shared utility classes.
3. Store all of your editable files (source code, static content, editable deployment descriptors) for modules in subdirectories of the EAR directory.
4. Set your WebLogic Server environment by executing either the setWLSEnv.cmd (Windows) or setWLSEnv.sh (UNIX) script. The scripts are located in the WL_HOME\server\bin\ directory, where WL_HOME is the top-level directory in which WebLogic Server is installed.
5. Use the weblogic.BuildXMLGen utility to generate a default build.xml file for use with your project. Edit the default property values as needed for your environment.
6. Use the default targets in the build.xml file to build, deploy, and package your application.

WebLogic Diagnostics Framework

WebLogic Diagnostic Framework (WLDF) is a monitoring and diagnostic framework that defines and implements a set of services that run within BEA WebLogic Server processes and participate in the standard server life cycle. WLDF falls somewhere between the old way of monitoring the environment (using the console or developing JMX based monitoring tools) and the fancy third-party JMX and SNMP monitoring tools.Using WLDF, you can create, collect, analyze, archive, and access diagnostic data generated by a running server and the applications deployed within its containers.WLDF includes several components for collecting and analyzing data:

• Diagnostic Image Capture: Creates a diagnostic snapshot from the server that can be used for post-failure analysis.
• Archive: Captures and persists data events, log records, and metrics from server instances and applications.
• Instrumentation: Adds diagnostic code to WebLogic Server instances and the applications running on them to execute diagnostic actions at specified locations in the code, usually at the beginning or end of a method (achieved using AspectJ) . The Instrumentation component provides the means for associating a diagnostic context with requests so they can be tracked as they flow through the system.
• Harvester: Captures metrics from run-time MBeans, including WebLogic Server MBeans and custom MBeans, which can be archived and later accessed for viewing historical data.
• Watches and Notifications: Provides the means for monitoring server and application states and sending notifications based on criteria set in the watches.
• Logging services: Manages logs for monitoring server, subsystem, and application events.

WLDF provides a set of standardized application programming interfaces (APIs) that enable dynamic access and control of diagnostic data, as well as improved monitoring that provides visibility into the server. Independent Software Vendors (ISVs) can use these APIs to develop custom monitoring and diagnostic tools for integration with WLDF.
WLDF was a new feature in WebLogic Server 9.0. WLDF enables dynamic access to server data through standard interfaces, and the volume of data accessed at any given time can be modified without shutting down and restarting the server.
References

• Introduction to Weblogic Diagnostic Framework (WLDF)
• Configuring and using Weblogic Diagnostic Framework

WebLogic Server and Oracle RAC

Oracle Real Application Clusters (RAC) is a software component you can add to a high-availabitlity solution that enables users on multiple machines to access a single database with increased performance. RAC comprises of two or more Oracle databases instances running on tow or more clustered machines and accessing a shared storage device via cluster technology. Oracle RAC offers the following features to applications on WebLogic Server:

• Scalability: A RAC appears lika a single Oracle database and is maintained using the same tools and practices. All nodes in the cluster execute transactions against the same database. RAC coordinates access to the shared data to ensure consistency, and integrity. Nodes can be added to the cluster without partitioning data (Horizontal scaling).
• Availability: Depending on the configuration, when a RAC node fails, in-flight transactions are redirected to another node in the cluster either by WebLogic Server or Oracle Thin driver. The fail-over is not for failed connections. Fail-over is only for transactions, which will be driven to completion, based on the time of failure.
• Load Balancing: BEA supports load balancing capability with Oracle RAC servers, through multi-data sources
• Failover: BEA recommends using WebLogic JDBC multi data sources to handle failover. Transparent Application Failover is not supported with WebLogic Server due to the requirement of Oracle OCI driver which is not supported by BEA.

Configuration Options
BEA supports several configuration options for using Oracle RAC with WebLogic Server:

1. Multiple RAC instances with Global Transactions: BEA recommends the use of transaction-aware WebLogic JDBC multi data sources, which support failover and load balancing, to connect to RAC nodes.
2. Multiple RAC instances without XA transactions: BEA recommends the use of (non-transaction-aware_ multi data sources to connect to the RAC nodes. Use the standard multi data source configuration, which supports failover and load balancing.
3. Multiple RAC nodes when multi data sources are not an option: Use Oracle RAC with connect-time failover. Load balancing is not supported in this configuration.

LimitationsA detailed explanation of the following limitations can be found on WebLogic site

1. Since Oracle requires that a Global Transaction must be initiated, prepared, and concluded in the same instance of the RAC cluster, and since Oracle Thin driver cannot guarantee that a transaction is initiated and concluded on the same RAC instance when when the driver is configured for load balancing, you cannot use connect-time load balancing wihen using XA with Oracle RAC.
2. There is a potential for Inconsistent Transaction Completion
3. Potential for Data Deadlocks in Some Failure scenarios
4. Potential for Transactions Completed out of sequence.