Hi Steve,
Thank you for your very detailed email and appreciating the work put in
by GlassFish team. Here are the points I would like to bring up:
1. OSGi + Java EE hybrid application support is not entirely a
proprietary feature of GlassFish. They are primarily based on OSGi
Enterprise Specification v4.2., which was released on Mar 2010. If the
screencast has given this impression, then we failed to convey things
correctly. Hybrid Application support in GlassFish can be roughly
divided into the following categories:
a) OSGi + Web: This is as defined in the aforementioned spec. It enables
use of OSGi in Web applications.
b) OSGi + JPA: This is also spec defined. GlassFish has some code that
ensures JPA lazy loading etc. works in all OSGi frameworks as opposed to
some other solutions that rely on proprietary OSGi framework APIs.
c) OSGi + EJB: This is proprietary to GlassFish. This is a very powerful
feature that automatically makes EJBs as available as OSGi services
without user having to depend on OSGi APIs or changing any source code
of their EJBs. By virtue of this feature, an OSGi developer can
implement transactional, secured, persistence aware, enterprise grade
OSGi service using EJB technology. BTW, this works in our web-lite
distribution as well. We highlighted all these in that screen cast.
d) OSGi + CDI: It allows injection of OSGi services using CDI. This is
done using a CDI portable extension, which means, it will work in any
application server that supports OSGi & CDI.
e) Other EE APIs like OSGi/JTA, OSGi/JDBC, etc: These are all defined in
the OSGi spec.
If you don't use #c, then you are free to use #b & #e directly in your
code to define enterprise grade OSGi service.
Like GlassFish, there are a couple of other open source projects where
OSGi Enterprise specs are being implemented as well. If you search the
net, you shall have little difficulty in finding them. In fact, there
are other application servers which support such features as well.
I hope this answers your first main concern.
2. Regarding your concern about packaging of Hybrid Application, I must
say I don't understand your concern very well. I will try to address
what I gathered from your email and you can ask further. Except
Export-EJB header, which is used only for feature #b, rest of the
manifest headers are standard headers. The pattern use in implementation
of hybrid application support is a well known pattern in OSGi world
called Extender Pattern. Look at the JavaONE slides which talks about
them. I also don't know where you got this impression of use of HK2 in
implementation of these features. HK2 is an internal detail of GlassFish
and neither these features nor their implementation is anyway influenced
by HK2. They are written purely on the assumption that GlassFish is
running as a set of OSGi bundles.
3. Interacting with users in this forum, I can say that some of them are
seriously considering use of this technology in their systems, but I
will let them say that.
4. I should also say that OSGi + Web application support was first
introduced in GlassFish v3 release, the rest of the features are
implemented as part of GlassFish v3.1, which is currently under active
development [2].
Last, but not the least, please feel free to exchange your ideas on this
subject in this forum - this is a very new area, so we are constantly
looking for exchange of ideas and opinions to make things better.
Thanks much,
Sahoo
[1]
http://www.slideshare.net/wwwsahoo/osgi-and-java-ee-a-hybrid-approach-to-enterprise-java-application-development
[2]
http://wikis.sun.com/display/GlassFish/3.1OSGi
On Wednesday 13 October 2010 06:25 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