On Wednesday 13 October 2010 11:40 PM, Daoud Abdelmonem Faleh wrote:
> 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?
>
That's the plan. I am yet to test them though.
> 2- How web frameworks (JSF in particular) support is doing under
> this kind of projects?
>
JSF is supported. There is one known bug which we are working on,
otherwise JSF2 is pretty well supported.
> 3- Would be possible to split a JSF web front into many modules?
> Let say each tab in a separate bundle for example?
>
Each web application maps to a bundle, but you can have several fragment
bundles attached to the main bundle, so yes, you can split your web app
into multiple bundles, but only one of them can be a main bundle and the
rest will be fragment bundles.
> 4- Is there any DOSGi implementation planned?
>
Not in 3.1 rel.
> 5- Splitting API exposed as a Web Service and its implementation
> into different modules?
>
Yes, that should be possible.
> 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?
>
It is definitely possible to install other OSGi enabled frameworks. It
all boils down to how robust and modular GlassFish and those bundles are.
> 7- What about EJB timer service discovering/running jobs installed
> as OSGi bundles?
>
Certainly possible. You can write a EJB timer, inject the desired OSGi
service into the EJB and call the service when timer fires. Let me know
if you need code fragments for this.
> 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.
>
>
Look forward to your feedback. Feel free to contact us in this forum. We
are pretty busy in implementing 3.1 release, so you may find some delay
in responses, but we will surely reply.
Thanks,
Sahoo
> 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
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>