Posts Tagged ‘WebSphere’

At DevoxxBE2012, Tim Ward and Holly Cummins, both seasoned experts in OSGi and enterprise technologies, delivered a comprehensive exploration into leveraging Enterprise OSGi for constructing modular applications. Tim, affiliated with Paremus and a key contributor to Apache Aries, alongside Holly from IBM, who focuses on WebSphere and performance tooling, guided attendees through the intricacies of transforming traditional Java EE setups into dynamic, OSGi-based systems. Their session bridged familiar concepts like WAR files and dependency injection with OSGi’s modularity, addressing common pain points in class path management.

They initiated the discussion by outlining Enterprise OSGi’s origins and relevance. Emerging in 2010, this specification enhances OSGi’s core, which has powered embedded systems and IDEs like Eclipse for over a decade, to better suit server-side enterprise needs. Tim and Holly emphasized how it integrates seamlessly with application servers, enabling features such as web applications, database interactions, and transaction management within an OSGi framework.

A key theme was the modularity crisis in large Java EE projects. They illustrated how sprawling WAR files, often exceeding server sizes like Tomcat’s 7MB core, accumulate unnecessary libraries, leading to class path hell. By contrasting tangled dependency graphs with OSGi’s structured approach, they demonstrated how explicit module definitions simplify maintenance and foster cleaner architectures.

Embracing OSGi Modularity Basics

Delving deeper, Tim and Holly explained OSGi’s bundle model, where each bundle—a JAR with added metadata—declares imports and exports via manifests. This enforces visibility rules, preventing accidental dependencies and promoting intentional design. They highlighted how bundles resolve dynamically, allowing runtime adaptability without redeployments.

The duo addressed common misconceptions, asserting that OSGi simplifies both complex and straightforward tasks. For instance, they showcased how dependency injection via Blueprint or Spring works effortlessly in OSGi, maintaining developer familiarity while adding modularity benefits.

They also touched on third-party library integration, noting challenges with non-OSGi JARs but solutions through tools that convert them into bundles. This ensures compatibility, reducing the bloat from redundant inclusions like JavaMail APIs.

Transitioning from WAR to WAB

A pivotal segment focused on evolving WAR files into Web Application Bundles (WABs). Tim and Holly demonstrated this migration, starting with a standard WAR and incorporating OSGi manifests to define it as a bundle. This shift enables deployment in OSGi containers like Apache Karaf or WebSphere Liberty, preserving servlet functionality while gaining modularity.

They illustrated error handling advantages: OSGi fails fast on missing dependencies, unlike runtime surprises in traditional setups. Through live examples, they showed bundles starting only when requirements are met, enhancing reliability.

Furthermore, they explored dynamism, where services can be added or removed at runtime, updating applications without downtime. This transparency in remoting and service interactions aligns with Java EE goals but executes more fluidly in OSGi.

Handling Dependencies and Repositories

Tim and Holly then examined dependency management, advocating explicit declarations to avoid hidden assumptions. They introduced bundle repositories, akin to Maven but tailored for OSGi, which automatically provision required bundles. This centralizes library control, aiding compliance in regulated environments.

In demonstrations, they deployed applications across servers like Liberty and Karaf, resolving dependencies on-the-fly. For instance, adding Joda Time via a repository revived a stalled bundle, showcasing practical modularity.

They stressed architectural enforcement: OSGi’s rules prevent poor practices, but good design remains essential. Tools like Eclipse plugins aid in visualizing and managing these structures.

Demonstrating Dynamism and Best Practices

The session culminated in hands-on demos, where a simple web app evolved into a dynamic OSGi system. Starting with a basic servlet, they integrated services for runtime changes, like toggling UI elements without restarts.

Tim and Holly concluded by reinforcing OSGi’s power in enforcing scalable, maintainable systems. They recommended resources, including their book “Enterprise OSGi in Action,” for further learning. Their presentation underscored how Enterprise OSGi not only resolves class path issues but elevates enterprise development to new levels of flexibility and efficiency.

Links:

• Holly Cummins on LinkedIn
• IBM website

Abstract

You have an application deployed on WebLogic 10 (used version for this tutorial: 10.3.3). You have to use an external provider for JMS, in our case MQ Series / WebSphere MQ.
The client side is a Mule ESB launched in standalone.

Prerequisites

You have:

• a running WebLogic 10 with an admin instance and an another instance, in our case: Muletier.
• a file file.bindings, used for MQ.

JARs installation

• Stop all your WebLogic 10 running instances.
• Get the JARs from MQ Series folders:
  • providerutil.jar
  • fscontext.jar
  • dhbcore.jar
  • connector.jar
  • commonservices.jar
  • com.ibm.mqjms.jar
  • com.ibm.mq.jar
• Copy them in your domain additional libraries folder (usually: user_projects/domains/jonathanApplication/lib/)
• Start WebLogic 10 admin. A block like this should appear:
  [java]<Oct 15, 2010 12:09:21 PM CEST> <Notice> <WebLogicServer> <BEA-000395> <Following extensions directory contents added to the end of the classpath:
  C:\win32app\bea\user_projects\domains\jonathanApplication\lib\com.ibm.mq.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\com.ibm.mqjms.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\commonservices.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\connector.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\dhbcore.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\fscontext.jar;C:\win32app\bea\
  user_projects\domains\jonathanApplication\lib\providerutil.jar>[/java]

Config

• Get file.bindings, copy it into user_projects/domains/jonathanApplication/config/jms, rename it as .bindings (without any prefix)
• Launch the console, login
• JMS > JMS Modules > Create JMS System Module > Name: JmsMqModule. Leave other fields empty. > Next > target server MuleTier > Finish
• Select JmsMqModule > New > Foreign Server > Name: MQForeignServer > keep check MuleTier > Finish
  • Select MQForeignServer >
    • JNDI Initial Context Factory: replace weblogic.jndi.WLInitialContextFactory with: com.sun.jndi.fscontext.RefFSContextFactory
    • JNDI Connection URL: set the URI of the folder containing the .bindings file, eg: file://c/win32app/bea/user_projects/domains/jonathanApplication/config/jms
  • Tab Connection Factories > New >
    • Name: MQForeignConnectionFactory
    • Local JNDI Name: the JNDI name on WebLogic side, eg: jonathanApplication/jms/connectionFactory/local (convention I could observe: separator on WebLogic: slash '/' ; unlike clients for which the separator in a dot '.')
    • Remote JNDI Name: the JNDI name on MQ side, eg: JONATHAN_APPLICATION.QCF
    • OK
  • Tab Destinations > New >
    • Queue of requests:
      • Name: JONATHAN.APPLICATION.REQUEST
      • Local JNDI Name: JONATHAN.APPLICATION.REQUEST
      • Remote JNDI Name: JONATHAN.APPLICATION.REQUEST
    • Queue of response:
      • Name: JONATHAN.APPLICATION.REPONSE
      • Local JNDI Name: JONATHAN.APPLICATION.REPONSE
      • Remote JNDI Name: JONATHAN.APPLICATION.REPONSE
    • NB: usually, MQ data are upper-cased and Java’s JNDI names are low-cased typed ; anyway (because of Windows not matching case?) here we use uppercase in for both names.

Mule

This part of the tutorial deals with a case of Mule ESB being your client application (sending and/or receiving JMS messages).

• Get the archive wlfullclient.jar (56MB). Alternatively, you can generate it yourself: go to the server/lib directory of your WebLogic installation (usually: C:\win32app\bea\wlserver_10.3\server\lib, and run: java -jar wljarbuilder.jar
• Copy the archive into $MULE_HOME/lib/user
• Copy the seven jars above (providerutil.jar, fscontext.jar, dhbcore.jar, connector.jar, commonservices.jar, com.ibm.mqjms.jar, com.ibm.mq.jar) into the same folder: $MULE_HOME/lib/user
• You can launch the mule. The config file is similar to any other configuration using standard JMS.