This morning I attended a talk on Enterprise Integration with Spring by Mark Fisher. It was part one of a two part talk. Part 1 was basically an introduction to Spring combined with an introduction to EAI. About the only thing I got out of it was to see some of the new features in Spring 2.5. It was a good introduction for anyone who hasn't been introduced to EAI principals.
In the second session of the morning, Hal Hildebrand from Oracle talked about what could be their next generation application server. It was an intriguing talk and made me think quite a bit about the architecture for the platform we're building out. It allowed me to compare and contrast the two and think about which ideas we could leverage. Basically, Hal laid out that it would be based on OSGi and Spring. It will essentially be a distributed grid with a single agent on each node talking to daemon processes locally through JMX. The agents are purely for coordination and the daemons do the actual work. The agent plus daemon concept reminded me a little of DB2's architecture of coordinators and agents. For what sounded like autonomous management he also discussed the use of rules engines on each of these agents that would basically act as a distributed expert system. The question I would've liked to ask him but didn't is will they support multiple component models (Java EE, JBI, SCA, etc.). He alluded that it would, but he also talked about the fact that Java EE is dead, so it was difficult to tell for sure.
1 comment:
As to your question as to whether we would support multiple component models, the answer is - of course - yes. First, there's the multiple component models in OSGi, itself. Namely, OSGi Declarative Services, Spring Declarative Modules for OSGi (which I happen to be a committer), IPOJO (from the felix folks), SCA (they're integrating into OSGi through negotiations with the OSGi Enterprise Expert Group, Google Guice and even JBoss' OSGi integration of SEAM. As for traditional component models, such as JEE, it's important to note that JEE already runs under OSGi today - in the form of Websphere, which is an OSGi application which provides a JEE container, as well as excellent open source projects such as EasyBeans, which provides much more OSGi integration of an EJB container and can integrate the hosted EJBs with OSGi services and export these EJBs as OSGi services for use in the container by non-JEE components.
WRT JEE is dead, that's not quite what I meant to convey. JEE has effectively jumped the shark and the vast changes that JEE has been making have been moving JEE to a POJO model which is virtually indistinguishable from frameworks such as Spring. This doesn't mean that JEE is "dead", merely that it seems to have reached the end of useful innovation and is essentially conceding that the POJO model has won.
Given that our customers have massive amounts of existing code which depends on JEE, it would be foolish for any new container model not to provide at least some level of support for it. The message I was hoping to convey in my talk, but obviously failed in doing so, was that the plan was to provide first class support for JEE in the form of technology like EasyBeans where we run JEE natively in OSGi and seamlessly integrate it into the OSGi environment, as well as providing the means to run OSGi in traditional JEE application servers where the OSGi components can integrate back into these traditional servers. In this way, the bridge to new technologies should be painless and won't require a massive recoding effort based on a new technology.
Of course, systems written on Spring, or new systems will be able to reap the benefits of the new technology in a way that these other component frameworks such as JEE will not be able to. Systems like SCA, which are currently in flux, are currently doing the work necessary to ensure that they can fully participate in the OSGi container so that customers using this technology can take advantage of OSGi and other OSGi component models can take advantage of them.
Again, I apologize for not making this clear in my talk.
Post a Comment