First of all congratulations to all the folk at SpringSource on the release! I know many of them personally and they are all great guys, great engineers and forward thinking innovators. Shipping an application platform is the next natual evolution for them and I look forward to their release stimulating further innovation from all the vendors in this space.

Now of course I don't personally see this as innovation. Event Server (WLEvS) is a lightweight application platform built using OSGi, Spring and Spring-DM. Indeed, as someone pointed out on TSSJ, BEA has been an active contributor to the Spring-DM project - and we have been using it in BEA products - since its inception. Spring-DM is central to WLEvS, it represents the programming model for WLEvS developers, much like it does in S2AS, and we have extended it using standard Spring hooks. Likewise we have a deployment model based on OSGi bundles, moniitoring, logging, management - the list goes on and I won't bore you with all the URLs. So you can see why claims that S2AS is ground-breaking in some way leave me a little nonplussed. Even OSGi-based LTW, which I think is one of the truly cool features of S2AS, has been around for a while. And the TSSJ comment that accessing OSGi services from webapps was a game-changing innovation, we have been doing for two years now! (We actually found that publishing OSGi services inside a webapp's JNDI tree made a lot more sense to users.)

I do like the dynamic provisioning features of S2AS, although this is not a great deal different to the maven integration done by xbean and initially integrated into Spring-DM by your truly. The key thing is that the SpringSource guys have productized it with a bundle repository backing it. Indeed, that's really the essence of what they have done - taken a set of existing technologies, in various states of readiness, and integrated them into a cohesive, production-quality whole. When I talk to customers that's one of the things they like about Spring in general - it pulls together other open source projects in a way that makes them easy-to-use, with all of the integration issues resolved.

I must talk a little about the choice of GPL3 license since it has generated a fair amount of controversy. In my opinion the use of GPL is a mistake. Here's why - SpringSource are a commercial outfit, ultimately they are valued on how well they are able to generate returns on their assets (consultants, IPR, user base etc). Free does not contribute to this. If something is free, regardless of whether it is GPL3 or ASL licensed, it does not contribute directly to this financial return. What matters is what is called in the literature "strategic complimentaries" (if you want the full story read my upcoming MBA thesis ;)) - basically stuff that you control (and can protect) that you can make money off that is driven by the usage of the free stuff. Things like training, consultancy, other proprietary software, support, subscriptions etc - all the things that SpringSource do so well. But the value derived from these things is dependent on one key ingredient - market penetration of the free stuff. The more the free stuff is accepted by the market, the more the stuff you make money off is worth. In fact it gets better than this - get enough penetration and customers will hesitate to use a competitor, a host of 3rd-party services will grow up around your free stuff (what are called "network effects") and customers will end up with switching costs that are too high to be worth contemplating - things like retraining all your developers, getting different tools etc, etc. So penetration is the key. Now you tell me, which license - GPL3 or ASL - is likely to achieve more penetration? The answer is self-evident. So what if some big competitor copies your invention - your invention is free anyway so who cares - what matters is that it's increasing the value of the stuff that matters do you. So I'm with Billy - the application platform will become commodity and its in SpringSource's interest for this to be the case.

Ok I'll get off my soapbox. Just to round this out, look out for the upcoming WLEvS 3.0 release, due out in the summer, which incorporates many of the features - and more - being considered by SpringSource for S2AS 2.0. Clustering, management console, single system image just to name a few.

The great thing is that since EvS is essentially an open platform, we can leverage these technologies bringing value-added functionality to market more quickly. Even better SPR-3608 turned out to be absolutely essential for EvS 2.0 and so, since Spring is open source, I was able to make the fix myself and allow EvS 2.0 to ship on time. Now that we are working on EvS 3.0 - which is based on Spring 2.5.x - I am able to pick up the official fix from Juergen and don't have to maintain a forked version of Spring 2.0.5.

This experience is not unique. Many features in Spring-DM, which we use heavily in EvS, were influenced by EvS requirements (or coded by me!). Although the SpringSource folks are quick to challenge stupid ideas, they are also cognizant of the fact that customers drive their business, and Costin graciously accepted the majority of my requests and submissions for Spring-DM. In fact one of the key features of Spring-DM - automatic activation of application contexts, which is essentially the EvS deployment model - was conceived and implemented by a BEA engineer.

As an engineer who has had to deal with a somewhat more glacial approach from other organizations, the approach is a breath of fresh air. And the key is open-ness - the open-ness of the EvS platform approach and the opensourciness [?] of many of the technologies that we leverage - not just Spring. This gives a great deal of comfort to our customers, since their commitment to our platform is not a case of vendor lock-in, but more a synergistic union of open technologies. They benefit not just from a fast turnaround on development, but wider understanding and support of the underlying technologies.

And the bug? Too embarrassing to discuss.

Why the interest in Spring? What has BEA to gain by so extensively using an Open Source technology in one of its products? Well the answer is actually pretty easy. Event Driven Architectures (EDA) are now reaching the mainstream both in terms of interest and in terms of development. They are a key part of Gartner's Extreme Transaction Processing (XTP) vision for the future - a vision in which BEA is currently in pole position. But enough of the marketing, developers want to know what it means for them in terms of their day-to-day jobs. At a development level EDA is significantly different to things like Java EE and thus requires new programming paradigms and environments. So building event driven applications requires something other than Java EE, but Java EE has a key advantage - its a standard and everyone is familiar with it. Love it or hate it is pretty easy to find developers with Java EE experience. But what happens when you need to do something new? Proprietary APIs are no good - all customers are wary of "vendor lock-in", and developers especially so. The answer is pretty simple - use something that developers are already familiar with. Hence, in a word, Spring.

BEA has a pretty long and positive history with Spring, as evidenced on our Spring resource page. But more than just providing a familiar programming environment, Spring provides a powerful extension mechanism for event server developers and a user friendly way of accessing OSGI services via Spring-OSGI. Furthermore we have used Spring 2.x's extension mechanism to implement WLEvS' domain specific language for network assembly. The nice thing about this is that if you don't know Spring you don't have to use it, but if you want to go deeper you still can.

The simple things are easy and the difficult things are possible, or as the Spring folks are fond of saying, "simple and powerful."

I have implemented an MDP sample attached to this arcticle. It requires maven2 to build, so make sure you download and install that first.

Take a look at MessageTraderBean.java in the sample. The guts of the implementation is onMessage() which simply receives a quote on a JMS topic and prints it out:

  public void onMessage(Message msg) {

    ObjectMessage tm = (ObjectMessage) msg;

    try {

      Quote quote = (Quote)tm.getObject();

      if (quote.getShares() > tradeLimit) {

        log("Trade " + quote.toString() + " was denied");

      }

      else {

        lastQuote = quote.toString();

        log("Received new quote : " + lastQuote);

      }

    }

    catch(JMSException ex) {

      ex.printStackTrace();

    }

  }

In order to the wire up the MDP we need a Spring configuration file which is src/main/webapp/WEB-INF/applicationContext.xml. Inside you can see various Spring classes being wired together, in this instance I am using org.springframework.jms.listener.DefaultMessageListenerContainer. For more information on these consult the Spring documentation. The one important thing to note here is the use of commonJ WorkManagers (I'm not going to show the code here since putting XML in a blog entry is such a pain!). Since we are going to be running the sample on WebLogic Server we don't want to start creating threads inside the application. Fortunately Spring 2.0 provides a way of deferring the asynchronous execution required by MDP's to WorkManagers as well as simpler thread pooling schemes. The WorkManager we are referencing is defined in web.xml (in the same directory) with WebLogic specific configuration in weblogic.xml. For more information on configuring WorkManagers consult the WLS documentation. For more information on Spring 2.0's TaskExecutor support consult the reference manual.

In order to use the example you need to create an appropriate JMS topic for publishing messages to. So fire up a server and start the console.

First of all you will need to create a persistent store for the server, so select Services->Persistent Stores and create a new FileStore. The name doesn't matter. You can select "." as the directory.

Next, you will need to create a JMS server using that persistent store. This is where the names start getting important in order for the Spring application to find the right topic. You will notice that I have called the destinationName in the applicationContext.xml "myserverJMSServer/spring-jms!quotes" which in English is translated as "the JMS server myserverJMSServer with JMS module spring-jms and topic quotes", so make sure that you call the new JMS server "myserverJMSServer". So select Services->Messaging-> JMS Servers and create a new JMSServer with that name and targetted at the persistent store you just created. Make sure also that you select the running server as a target.

Now you need a JMS module targetted at the JMS server. So select Services->Messaging-> JMS Modules and create a new JMS module called "spring-jms" and targetted at the running server. When asked if you would like to add resources, accept and create a new Topic resource called "quotes" and target it at myserverJMSServer. You don't need to set the JNDI-name for the topic.

You are now ready to deploy the application. Copy target/mdp-1.0-SNAPSHOT.war into the server's autodeploy directory. You should get a flurry of debug messages, but no exceptions. If you get an exception most likely you got one of the names wrong when setting up JMS. You may have to kill the server and start again if this happens since there was a bug in earlier releases of Spring 2.0 that caused the server to spew endless exceptions if the deployment names did not match. Hopefully this will not happen to you!

Once you have the app deployed, all that remains to do is to run the client. You can see that the guts of the client is to publish a message to a topic:

  public void example() throws RemoteException, JMSException, NamingException {
    Topic newTopic = null;
    TopicSession session = null;
    try {
      session =
        m_topicConnection.createTopicSession(false,   // non transacted
                                             Session.AUTO_ACKNOWLEDGE);
      
      newTopic = (Topic) m_context.lookup(TOPIC_JNDI_NAME);
    }
    catch(NamingException ex) {
      newTopic = session.createTopic(TOPIC_NAME);
      m_context.bind(TOPIC_JNDI_NAME, newTopic);
    }

    TopicPublisher sender = session.createPublisher(newTopic);

    ObjectMessage tm = session.createObjectMessage();

    String[] symbols = new String[] {

      "BEAS", "SUNW", "IBM"

    };

    float[] price = new float[] {

      13.10F, 4.50F, 89.89F

    };

    int[] shares = new int[] {

      1000, 50, 3000

    };

    for (int i = 0; i < symbols.length; i++) {

    tm.setObject( new Quote(symbols[i], price[i], shares[i]));

      sender.publish(tm);

    }

  }

eagle Andrew Piper> java -classpath "target/classes;$CLASSPATH" com.bea.spring.Client t3://eagle:7001

Beginning message.Client...

Success!  created topic: myserverJMSServer/spring-jms!quotes and published a message.

End message.Client...

Received new quote : 1000 of BEAS@13.1
Received new quote : 50 of SUNW@4.5
Received new quote : 3000 of IBM@89.89

If you have problems with the example let me know. I ran this with Spring 2.0 rc2 which is available from the maven repositories as well as WebLogic Server 9.1. There shouldn't be any problem running the example on later releases of either Spring 2.0 or WebLogic Server.

<bean id="jmxExporter" class="org.springframework.jmx.export.MBeanExporter">

  <property name="beans">

    <map>

      <entry key="petclinic:service=clinic" value-ref="clinic"/>

    </map>

  </property>

  <property name="assembler">

    <bean class="org.springframework.jmx.export.assembler.InterfaceBasedMBeanInfoAssembler">

      <property name="interfaceMappings">

        <props>

          <prop key="petclinic:service=clinic">org.springframework.samples.petclinic.jdbc.CachingClinic</prop>

        </props>

      </property>

    </bean>

  </property>

  <property name="listeners">

    <list>

      <ref local="mediator"/>

    </list>

  </property>

  <property name="autodetect" value="true"/>

  <property name="server">

    <bean class="org.springframework.jndi.JndiObjectFactoryBean">

      <property name="jndiName" value="java:comp/env/jmx/runtime"/>

    </bean>

  </property>

</bean>

  

<bean id="mediator" class="com.interface21.wl9.jmx.mediator.Mediator">

  <property name="applicationName" value="petclinic"/>

</bean>

The same applies to the interface mappings section further down. Note too that you must expose you beans via an interface, you cannot simply export a regular JavaBean. It is this interface that appears in the interfaceMappings section.

Finally the JMX exporter refers to a mediator that listens to events and publishes beans to the console as they are exported to JMX. The mediator section appears at the bottom, and again the applicationName must exactly match your application name, otherwise you will see no beans.

We plan to make the configuration of this much simpler very soon, so stay tuned. You can see the full set of properties for the MBeanExporter here. Likewise you can see the configuration properties for the InterfaceBasedMBeanInfoAssembler here.

Once you have your config sorted, you need to build your application and include the console client extension. Unfortunately there was a bug in earlier builds of this and doubly unfortunately the builds of client and server pieces need to match. So I include both the server jar and client jar libraries here. I have verified these with WebLogic Server 9.1 and Spring 2.0-m5. They should work fine with earlier versions of Spring. The extension has been designed so that the version of Sping used by the server piece does not need to match that used by the client piece. You will however need to bundle the appropriate Spring jars with your application also.

Finnaly you need to configure the server extension, this simply involves dropping the server jar into the console-ext directory of your WebLogic Server configuration. Start the server run the app and you should be good to go. The extension appears as an extra tab called "Spring Management Objects" under the deployment entry for your application in the console.

Gotchas - there are a bunch of things that can go wrong here:

• If the tab does not appear then you likely have not configured the server extension correctly. The other possibility is that you are using autodeployment. autodeployment does not work with the console extension, you must use regular deployment.

  
  

• If you get the tab but no managed objects then most likely your application name does not match the one you configured. Also check that you are using the correct versions of the console extension, both server and client shown above.
  
  
• Clustering is not really supported at present - the beans are exported to the JMX server of the server on which they reside. The console must therefore also be running on this server. Its probably possible to use WebLogic Server's federated JMX server to look up beans remotely, but I have not tried that as yet.