Thank you Sahoo for taking the time to run throw my requirement.
Kind Regards,
--Daoud.
On Sun, Oct 17, 2010 at 8:54 AM, Sanjeeb Sahoo <Sahoo_at_sun.com> wrote:
> 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
>>
>>
>
>