Hi *,
I am working for some time now on a new project which makes use of
OSGi/JavaEE hybrid stuff and until now it works rather well, besides
some bugs or smaller design issues.
What we currently have is a highly modular JavaEE application based on
around 10 different "components", each separated into 2 to 5 bundles, e.g.:
- API
- EJB service implementation
- JPA persistence implementation
- client model
- JAX-WS web service
So with the separation of concerns implemented by the bundles we have a
very clear and easy to understand application design/architecture. Other
components consuming a service just have to use classes from the API
bundle and eventually the client model and does not even know what there
is behind and shouldn't as we may change minds on implementation which
wouldn't break the API.
In addition what I have learned with this setup is that developing such
a highly modular application is very dynamic and development scales very
well if the key knowledge about OSGi and JavaEE exists at each side.
Also development is (at least subjective) faster than traditional JavaEE
development. Of course we use the latest bits here:
- JavaEE 6
- OSGi 4.2
- GlassFish 3.1 promoted
I read that you are about to implement a complex distributed system.
This makes me think about the following:
1. ESB:
Did you concider using an Enterprise Service Bus for interconnecting
those systems? If the various components are distributed and implemented
using different technology stacks this would make sense.
2. Apache Camel
If an ESB is too heavyweight you can still interconnect those components
using a "pure" message router.
3. Distributed OSGi
This is what I would consider for a rather lightweight setup involving
components at different locations. You still have to have the API on
each side but it is very transparent. I definitively have to look into
this as well regarding support by GlassFish management (e.g. I see the
opportunity to move a service from one server to another using some
asadmin command - live!).
In addition GlassFish 3.1 really improved in terms of OSGI/application
management capabilities using asadmin. There is little I would think
they missed out.
As Sahoo already mentioned the OSGi/EJB stack is the only one that is
proprietary currently and its value is really big. So I would wonder if
something similar wouldn't appear in one of the next OSGi enterprise
spec releases.
If you have further questions don't hesitate and ask. I'd like to share
what we currently have worked out.
Regards,
CHaoS
On 10/13/2010 02:55 PM, Steven Siebert wrote:
> Hello,
>
> I am at the architecture/design stages of building a large/complex
> enterprise system that will be operated over a distributed
> (multi-site/WAN) environment, which will be composed of numerous
> components with a resulting complex dependency matrix. To over simplify
> the description of the system, it will be composed of numerous reusable
> services and interconnected enterprise and web applications. To make
> management a bit more complicated, our team will be running this system
> on at least three segregated networks. All this makes me mindful of the
> maintenance and deploy/runtime management (provisioning, configuration,
> deployment, runtime-configuration) implications. I've already
> decomposed my system, and I know generally how I want it to behave, but
> at this scale, I'm finding that traditional EE architecture (n-tier) and
> management techniques (GF admin console, etc) just doesn't seem like it
> will be enough.
>
> In steps OSGi+EE hybrid applications.
>
> I've been following these developments for quite some time on Mr.
> Gupta's (http://www.java.net/blog/6125) and Mr. Sahoos
> (http://www.java.net/blog/111589) blogs, played with implementing Felix,
> converting some of my services to OSGi services that comply with core,
> compendium, or enterprise service APIs. Good times. Last night I
> implemented a simple hybrid application based on a recent screencast
> (http://blogs.sun.com/arungupta/entry/screencast_32_osgi_enabled_java),
> which was easy enough (BTW, well done GF team). GFv3 really provides
> some great facilities for OSGi bundle management. With all this good
> stuff, though, I have hesitations implementing my application in this
> hybrid manner.
>
> While GF is my application server of choice for both development and
> production, I can't assume my management/customers will feel the same
> way for all time into eternity. In its current state, hybrid
> applications are proprietary (I believe it was Arun who admitted this in
> the screencast), which certainly kills vendor neutrality. In addition
> to this, I can't help but feel that the way of going about packaging and
> deploying the hybrid application is a bit off from what I would like to
> see. Rather than building a bundle that depends on a service API (for
> example, a bundle that defines the web container or the EJB 3.1
> container API), I am modifying my bundle (added manifest properties) to
> run in the GF environment. While this isn't necessarily bad, especially
> since the OSGi spec says this is OK, I can't help but get the feeling
> that this scenario goes against the spirit of the OSGi. I believe this
> may be a result of the H2 kernel running on top of the OSGi container,
> rather than itself being services used by an OSGi container, which is
> understandable, but it gives me hesitance because it tells me that there
> is no future hope for vendor neutrality down this path (since the H2
> kernel isn't used by other vendors such as JBoss, etc). What I would
> like to see (I believe) is the ability for me to make an ejb module/web
> archieve/enterprise application, provide the OSGi-specific classes I
> want (ServiceTracker, etc) and simply deploy it to an OSGi container and
> allow me to pick/choose my service implementations for the web
> container/ejb container, etc.
>
> As far as my questions go....is there anyone out there that is
> implementing (or seriously considering implementing, as I am) hybrid
> EE6/OSGi applications in production? Does anyone have any thoughts on
> my views on the vendor neutrality aspect...or generally how the hybrid
> application is put together?
>
> Thanks,
>
> Steve