We have a project that we're working on and I'm floating the balloon about perhaps leveraging Glassfish for some core infrastructure.
My intent is not to just deploy some EJBs or WARs on it, but rather take Glassfish, toss it in a forge, beat on it with some hammers and have our project come out the other end.
The reasons for this is that many of the requirements for the project are already built in to Glassfish.
We need (among other things):
1) GUI admin console -- Check
2) CLI admin console -- Check
3) Centralized configuration -- Check
4) Multi machine management and deployment -- Check
5) Monitoring, Logging, Starting, Stopping, Laughing, Singing, Dancing, etc. etc. etc. -- Check, check, check (well, mostly).
You know, "infrastructure".
The project has two major components.
The first is a queue like component. On the one hand, it takes messages from N clients and stores them away. On the other, it feeds clients with the messages they request. It's not quite a JMS queue or topic because we have the ability "replay" messages from our queue to clients, and we can also stack these requests up (Client X is going to get all new messages, as well as a replay of all the messages from last Tuesday, and also the messages that have the XYZ property set to ABC). Another key distinction is that these message feeds are defined operationally, the clients themselves do not make these requests. Rather, then simply connect and say "more please".
The second component is a runtime component. These are the consumers of the queue component. Their primary role is to move messages from Q A to Q B, and run logic on the messages -- this is straightforward. The key here is we need to deploy these runtimes, start them, stop them, pause them, CRUD them. In theory we might be able to make JBI artifacts out of these and deploy on top of that, but that's not the path we've taken.
So, this is classic, generic, data processing stuff.
All of this stuff could be written from scratch. We have prototypes of the major components running now. The Queue component right now is a J2SE web service application using JAX-WS. We're not settled on web services, so this may change. But it is a request driven component.
The runtime component basically takes a list of definitions, and fires off a thread each, and lets them run merrily along. Each thread connects up to a queue component (incoming and outgoing) and does its thing.
But then we got in to discussing centralized configuration, deploying these things "on the fly", across machines. Chatting about the CLI, GUI, our JMX stuff we've already rolled in to this.
And it occurred to me that Glassfish already does all this, and it IS open source, so...maybe we could mate our components on top of it, get a "Free" GUI, a "Free" CLI, and all of the other goodies. And, hey, what the heck, let's leverage the connection pools and other bits as well.
Once upon a time, JBI/OpenESB was a stand alone project, off on the side. But now we get it built in to the app server (as well as a standalone project).
Why can't we do that? And how would we do that? How do we go about integrating something at that level?
Mind, I'm not opposed to leveraging the EJB parts of the container. If our Queue component can remain and work simply as a WAR, then, great. But for our users, who may want to deploy several of those components, we don't want them thinking of it, or dealing with it as a WAR. We want it to show on the GF console, underneath JMS Resources (or something). Click "Add New", target it to a machine, set some properties, etc. That's the kind of experience and integration we're looking at. That's what I mean by wanting to leverage Glassfish for itself, not necessarily (or soley) as an EJB container.
It seems to me that v3 is still too young for this. That what we'd like to do is, really, pretty incremental on top of what GF v2 already does. So, for good or ill, we'd have to work with the monolith that it v2 rather than the legos that is v3.
So, the big questions are:
Is this a good idea?
Does anyone read this and say "Are you MAD!?!?"?
Is it a practical idea? In that certainly there's benefits to adopting proven code and infrastructure, but at the same time there may be a steep learning curve to really leverage it.
What would be the best way to approach this? I've not seen a "hello world" for adding a component to the core server (not surprising, of course), and that process would be very enlightening I think.
I think we'd literally have to fork the server. I'd love to not have to do that, but I don't get the feeling it's as perfectly modular as perhaps we'd like it to be.
At the same time, however, I would like to think that the changes to actual GF source base would be minor. The core should remain untouched, most of our stuff will be in the admin area I would hope, and fringey connecting stuff. Another benefit of working with v2 is that the code is much more stable, so it's more likely we'll be able to keep up with changes for bug fixes and such.
Finally, any approaches I haven't thought of that perhaps would be better? Maybe y'all have this scenario all planned out and I missed the memo.
Thanx!
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=297499