I should say that i am at the early stage of a similar project, the
design phase has been done and we are considering making use of those
features. Thought still have to implement with another architect a POC
then would say if we're going into production with such design.
What I would like to know at this stage:
1- Clustering and HA would be available for hybrid EE applications?
2- How web frameworks (JSF in particular) support is doing under
this kind of projects?
3- Would be possible to split a JSF web front into many modules?
Let say each tab in a separate bundle for example?
4- Is there any DOSGi implementation planned?
5- Splitting API exposed as a Web Service and its implementation
into different modules?
6- Could be possible to install/use other OSGi enabled
frameworks/containers such as Apache Camel and have routing rules
managed as OSGi bundles and let it mediate between WS Stack, Web
Stack, EJB/OSGi Stack?
7- What about EJB timer service discovering/running jobs installed
as OSGi bundles?
I implemented a project with similar requirements (no web front) under
Apache Karaf OSGi runtime, and am looking for Clustering/HA and EJB
programming model into the current one under Glassfish. Tying my
implementation to a specific GF feature (OSGi/EJB) is *not* a problem
for me.
As I said I'll be experimenting with my setup and probably
blogging/tweeting about it if company policy permit it.
Kind Regards,
--Daoud
On Wed, Oct 13, 2010 at 4:53 PM, Sanjeeb Sahoo <Sahoo_at_sun.com> wrote:
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>