Modular, Pfft
Jun 5th, 2008 by sharps
So now every vendor is claiming a modular architecture for their enterprise Java runtime. This is progress and maybe OSGi really will become the standard framework for enabling modular architectures. Unfortunately people needed this capability 5 years ago.
It’s great to see the innovators rallying around such a good cause - but look at the dates !
“provide an up-to-date server model that gives enterprises the features they want.”
- Rod Johnson, Spring Source CEO - April, 2008 [link]
“GlassFish v3 has a modular, lightweight, extensible architecture”
Sun Employee, glassfish.net - June, 2008 [link]
“JBoss’ modular architecture means customers can also choose the features they want, instead of installing a full J2EE application server on devices with limited processing and memory capability.”
Marc Fleury, JBoss CEO, December, 2002 [link]
What you, Marc and others around JBoss seem not to understand with your “I was there first” claims, is that the most important thing is not what is possible but what is easy.
JMX has always been such a pain, not usable at all, so hard to integrate in enterprise development, and even if the purpose was somewhat similar, the solution was just unusable. All those issues are solved with OSGi.
You may have been the first ones to understand the full power of modularity, you just chose the wrong technology or you were too early.
What is sure is that this whole childish “there’s nothing new” attitude is not going to help JBoss survive the decline of monolithic J2EE.
I agree with Sebastien that “being first” is not terribly important unless you can follow-up with a “… and thus at this point we have incorporated a lot of experience into a product / marketplace / whatever that delivers A, B, and C for our customers and partners”.
GlassFish uses OSGi because (like Sebastien) we believe it is the right enabler, but I think the right focus should be on what we do with it.
Sebastien, Eduardo, with all due respect I beg to differ. Being first was indeed a huge advantage for JBoss. Remember how it completely re-defined the middleware market ? That was due to a) being the first open source product; b) being first with a modular JMX micro-kernel; and c) being first with a usable ORM technology - Hibernate. So far - being first has been a good strategy for JBoss.
My post was merely pointing out that claiming such features (modular, micro-kernel) are somehow new and innovative (6 years later) is disingenuous.
I personally don’t have a problem with OSGi - I liked it 4 years ago (enough to push for it’s inclusion in Sun Java App Server
and still like it. It’s also a part of the next JBoss App Server release.
Where I get really uncomfortable is when OSGi is touted as the replacement for Java EE - it’s not (yet).
Sebastian - JBoss has never been about monolithic J2EE - it’s always been about providing a modular run-time and promoting the best parts of EE and augmenting its weaknesses with things like Seam, Hibernate, etc. We’ll support EE as long as there are customers who need it (ie. a long time) but we’re not forcing EE or any other framework on anyone.
Being first with a viable Open Source AppServer certainly had a big benefit for JBoss, but your point was about modularity.
On that, I doubt anybody in the GlassFish community ever said we were the first modular server, but, if anybody did, that is incorrect. GFv3 *is* our first modular release in the GlassFish line (it would be incorrect to count our Java Embedded Server circa ‘98) and we think modular servers are specially important in today’s market. Anyhow, I doubt you are claiming that JBoss was the first modular server either, are you?
I have deep respect for JBoss role in the AppServer market. Then and now. And I surely don’t try to take anything away from that. Besides, JBoss participates in a number of our projects
[...] blogged - Modular Pfft : http://blog.softwhere.org/archives/177 [...]
I see two different debates here: modularity at the server runtime level is one thing, bringing this modularity to enterprise developers is something else. I might be wrong but from what I understand, JMX and now OSGi in JBoss, or OSGi in Glassfish are all about modularity “behind the scenes”. Even if JMX on JBoss made it possible to develop modular applications with SAR and so on, it was just not usable enough.
What is really powerful about S2AP is that, beyond the server runtime, application developers can really leverage this modularity very easily, with dependency management, services, versioning, etc. and all of that is based on a very simple and usable standard. THAT is new! That is what has the potential to change the way most of us develop and deploy our applications, from monolithic WARs and EARs to modular JARs, WARs and PARs (even if I’m not really fond of the PAR concept for now).
re: Sebastien - Yes, I agree, S2AP is pushing the envelope and is encouraging many more developers to program against osgi than GF, where this is currently positioned at the services/container-level. It will be interesting to see how it evolves; some of these things are just very hard to do, regardless of technology. Also we are all extending osgi a bit, in our case through hk2’s layer. But one of the reasons why we adopted osgi where we could is because that gives us the ability to participate in the conversation around these technologies in the industry and adjust our feature set as we all learn what’s best for the users.
@eduardo
> Besides, JBoss participates in a number of our projects
Indeed, with a few more candidates we need to discuss next week.
@sebastien
> I’m with you on JMX - it isn’t a technology that should be ‘inflicted’ on humans, and with JBoss AS 5 - users won’t see it anymore.
However - the service modularity in JBoss isn’t so much about JMX - you simply delete the service definitions and the services are gone - very simple, tried and tested.
Overall - there are interesting times ahead as we see how some of these developments play out.
Thanks for the comments, best regards, Rich
Hi,
All those comments about JBoss AS 5 are very nice and I understand that JMX integration will be much easier with JBoss 5. But would you be able to tell us when it will be stable and certified? I’ve been waiting for that for 2 years already ;).
To be honest, I helped several clients to migrate to JBoss 2 years ago and I’m starting to feel unconfortable about it.
Michael, thanks for the feedback - it’s always welcome and yes, AS 5 has taken longer than it should have. But then it’s really the first major re-factoring of JBoss AS ever. Getting the stability, scalability and performance to the levels that our large enterprise customers expect takes time.
Currently - I believe we’re getting close to a JBoss.org Candidate Release and we’re still pushing for a supported Platform release (JBoss EAP) towards the end of the year.
So, a question for you - what specifically is it that you or your clients are waiting for in AS 5 ?
- Rich
Hi Rich,
2 years ago I had to do a benchmark for several AS including JBoss. We have selected JBoss because it was the most appropriate one for my client’s need. However I can say that we’re hoping that the admin console will be improved. I’m not speaking of JBoss ON but about a simple admin console that would allow you to set up the size of a connection pool, define a datasource etc.
Is it on the roadmap?
Cheers,
Michael.
@Sebastien:
I like OSGi, I want OSGi. But, the problem, it is just as hard to expose an OSGi service as it was with our JMX kernel. More metadata in many situtions and just as complicated of an SPI.
My problem is not with OSGi, but with those pushing OSGi to end users. OSGi, IMO, is a framework and middleware developer thing. Middleware developers need it because we need a common spine to package and deploy our projects. BUT…IMO, it should not be pushed as an application developer consumable API for building services. Component dependency management should be delegated to the kernel/app server you are deploying into. There’s no reason the app server can’t figure out these dependencies for you.
@Michael - the plans for the admin console are to take an appropriate sub-set of JON 2.0 features and embed them in the App Server - so yes, some fairly radical ‘ease-of-use’ improvements are planned. Note - this ‘embedded console’ may not be in the initial candidate release of AS 5.0 but will be in whichever version we pick up for EAP 5.0.
- Rich
[...] Back to the SpringSource Application Platform. I respect Rod and SpringSource a ton and I love how the Spring Framework has changed the way I write software, but I have to wonder if part of this is marketing cruft related to the fact that Spring Source is now touting their own application server. My biggest complaint is against all the talk about how the SpringSource Application Platform is so modular with all of it’s OSGI-loaded goodness. JBoss had a modular application server in 2002! [...]