Comments on: OSGi – The placebo that will rejuvenate this industry (just ask your vendor)

By: Why is OSGi on everyone’s tongue – or why you should take the red pill | SOA Governance - Service Oriented Architecture - SOA Business - SOA Design - SOA Services - SOA Software - SOA Solutions - SOA Security - SOA Web Service

Tue, 15 Sep 2009 18:02:15 +0000

[...] a JBoss blog on “OSGi – The placebo that will rejuvenate this industry (just ask your vendor)” Sacha paints a picture of everyone just following the latest buzz-word and (at least in title) not [...]

By: OSGi « …in search of INTEROPerabilitY…–>|<–

Fri, 15 May 2009 13:40:00 +0000

[...] Blogs: OSGi – The placebo that will rejuvenate this industry (just ask your vendor) [...]

By: Sacha

Sacha — Fri, 06 Jun 2008 17:52:02 +0000

Hello Alin,

For some services, yes, you are right: they could be easily added on top of OSGi i.e. standardized as specs sitting on top. However, given that these specs do not exist yet, how is that different from what we did i.e. we implemented our own solution Would we be willing to standardize this? Sure, if the community thinks (post-GA) that this is worth being standardized, we will gladly do so much like we did with Hibernate/JPA and Seam/WebBeans.

However, there are some features that probably couldn’t easily be standardized as part of OSGi. OSGi provides a pretty coarse-grain model and does it well. But finer-grain model are less ideal to implement on top of OSGi.

With our solution, that shouldn’t be a big deal though: if you like what we did, let’s standardize, if you don’t, let’s keep it as is

Cheers,

Sacha

By: Alin Dreghiciu

Alin Dreghiciu — Fri, 06 Jun 2008 17:39:18 +0000

Hi,

For the start I’m pretty much fan of OSGi.
What I’m missing in your blog is some pointers details about why the “services lifecycle and extended dependency management, deployment customization, metadata management,etc…” cannot be implemented on top of OSGi. What are the requirements that you would have, where OSGi stands against you, because at its basics feature (the core specs) you “only” get the module layer and the service registry.

Thanx,
Alin Dreghiciu

By: Sacha

Sacha — Fri, 23 May 2008 20:14:37 +0000

EE supported,

Yes, it is true that the EE specification in itself provides a great deal of portability. However, it is also true that some specific behaviour of app servers will most probably never be standardized or are left to the interpretation of each implementation. Those items are the ones slowing down migration and for which vendors usually provide help/tools/guides to speed up migration to their AS.

Cheers,

Sacha

By: EE supported\

EE supported\ — Fri, 23 May 2008 17:58:08 +0000

My understanding is, Yes Sacha, and jBoss is working toward increasing
the level of interoperability between products. At least by means of
working with the JCP in the evolution of Java EE specification. jBoss
has and is very involved with keeping standards. So, in this sense I do
see Jboss helping Improve interoperability. If Java EE continues to grow
and become a higher standard, customer like yourself should be able to
develop all your apps and distribute to any Java EE vendor.
Making your company even more profitable.

By: Sacha

Sacha — Wed, 21 May 2008 07:32:22 +0000

Meredith,

I think you should speak to SUN. Our role is to help you migrate from any app. server to JBoss, not the opposite. Much like I guess, the role of your company is to develop its own services/products, not the one of your competitors.

Cheers,

Sacha

By: Meredith Ples

Meredith Ples — Tue, 20 May 2008 23:24:52 +0000

My company is starting to migrate to Sun’s new Glassfish AS off of JBoss, and I was wondering if you were working with Sun to increase the level of interoperability between your products. From a customer perspective, that would make me think more highly of JBoss – do you have any pointers for transitioning?