|Steven Siebert||Oct 13, 2010 5:55 am|
|Sanjeeb Sahoo||Oct 13, 2010 8:51 am|
|Daoud Abdelmonem Faleh||Oct 13, 2010 11:10 am|
|glas...@javadesktop.org||Oct 13, 2010 12:31 pm|
|Sanjeeb Sahoo||Oct 13, 2010 12:36 pm|
|glas...@javadesktop.org||Oct 15, 2010 6:18 am|
|Sanjeeb Sahoo||Oct 15, 2010 6:45 am|
|glas...@javadesktop.org||Oct 15, 2010 7:29 am|
|Sanjeeb Sahoo||Oct 15, 2010 7:42 am|
|Sanjeeb Sahoo||Oct 17, 2010 12:53 am|
|Daoud Abdelmonem Faleh||Oct 17, 2010 5:45 am|
|PostMasteR||Oct 19, 2010 12:19 am|
|glas...@javadesktop.org||Oct 22, 2010 8:35 am|
|Subject:||Re: Anybody using hybrid (EE+OSGi) applications in production?|
|From:||Daoud Abdelmonem Faleh (abde...@gmail.com)|
|Date:||Oct 13, 2010 11:10:11 am|
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 <Sah...@sun.com> wrote:
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 .
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
On Wednesday 13 October 2010 06:25 PM, Steven Siebert wrote:
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?