I am pretty sure you have heard about SCA (Service Component Architecture) by now. It is hosted by OSOA at http://www.osoa.org.
Since pretty much the same players that are working on SCA are also members of the OSGi Alliance, it seems natural to find common grounds between the two.
At the inception of the Enterprise Expert Group (EEG) in January 2007, we already discussed the possibilities in combining the two technologies somehow. We started RFP 81 to capture the requirements and use cases. For some reason, the RFP was never really paid as much attention to as other EE related RFPs. Given the fact that several companies are bringing out SCA based or supporting products (TIBCO with ActiveMatrix, IBM, Oracle, etc.) the RFP deserves another close look and some tender love and care.
I, myself, am not particularly an expert in SCA, but I begin to grasp the differences in the modular, dynamic, and service oriented architecture of OSGi versus the more deployment oriented, static service composition model of SCA. Candidly, I would summarize this as 'SCA wants to rule the world in large', while OSGi is happy in ruling the services and modularization in context of a single technology and JVM process. SCA is technology independent, OSGi by all means of current practice is JAVA bound.
What do they have in common that is worth specifying?
Well, for one thing, there are more and more customers out there that understand and like the OSGi service programming model. Thanks to component technologies like Spring it becomes very easy to structure a big hairy and complex application as a collection of small beans, which are packaged up as bundles. In the EEG we specified Blueprint Service as part of the EE Edition of OSGi, which will come out some time later this year. For those who don't know or forgot, the RI of Blueprint is the version 2.0 of Spring Dynamic Modules.
Now, if I use SCA to describe my big scary application deployment or domain in SCA terms, can I make my OSGi bundled application part of that SCA domain? I think, it should be as simple as modeling my application as a SCA composite, define the implementation type as implementation.osgi, promote my references as services via the OSGi service registry, and use Configuration Admin to configure the application at runtime. Sounds easy, doesn't it?
Turns out, not so much. I recently discussed this with one of my fellow EEG members during our last face-2-face meeting in Bedford, MA. Apparently, SCA doesn't like the constraint so much that services and references are bound to a particular binding type (OSGi service registry). Their ability to function depends on the fact that those other services are co-deployed with the application in the same OSGi framework.
However, there are a few things that can be done about this.
* the SCA runtime could start a framework dedicated to the OSGi application and wire the external services and references using SCA means. In case the SCA runtime is built itself as an OSGi application, the new RFC 138 Multiple Frameworks specification in OSGi comes in very handy. It allows an OSGi framework to efficiently manage a child framework.
* remove the restriction of having OSGi services only available to the local OSGi framework. This is the power of RFC 119 Distributed OSGi scheduled to be released as part of the EE Edition later this year. When services are now distributable or at least accessible across the JVM process boundaries, then the OSGi binding type becomes interesting for SCA applications again. One of the advantages of RFC 119 is that this scenario has native support for the SCA intent model. So, matching services and references based on intents with the option of additional metadata for policies makes the integration of SCA and OSGi look natural and seamless.
Join our talk about Distributed OSGi at EclipseCon 2009 to hear exactly how this is going to work for you.
As you were...
Showing posts with label OSGi. Show all posts
Showing posts with label OSGi. Show all posts
Monday, January 26, 2009
Thursday, October 16, 2008
BundleFest in Montpellier
It must have been beginning of 2008 or even earlier that Peter Kriens (Technical Director of the OSGi Alliance) has first pitched the idea of gathering some of the expert groups members together for a week of intensive collaboration. At the time, the idea became more and more appealing as we were fantasising about sitting next to the pool in southern France while drinking wine and philosophizing about OSGi. I kind of signed up immediately, not knowing whether I would actually be able to attend.
Now, in October 2008, we actually did meet in Montpellier, France. The hotel 'La Grande Motte' was chosen by Peter as the hosting location and turns out to be an excellent ambiente for this kind of collaboration. We gathered in a small room near the waterfront for 9 to 10 hours a day, only breaking for coffee and lunch every once in a while. Actually, we took our breaks very seriously :-) The food was delicious French cuisine with appetizers and dessert. I probably gained a few pounds during this week.
Work wise, we focused on the most pressing outstanding action items like the OSGi build, their test cases, and of course, my child, RFC 119 - Distributed OSGi. Having David and his colleagues as well as my former Siemens colleagues together in the same room at the same time was very helpful. Siemens committed their RI for the Discovery part and I completed the TCK within the first 2 days. In the meantime, David assembled all of the CXF based RI into a single bundle to make it usable from the OSGi build. I was not able to complete the full TCK, but pretty much everything is there to finish it alone at home in Palo Alto.
We had some very interesting and controversial discussions:
If the RFC claims that it provides for distribution of OSGi services, does the TCK need to verify this claim by deploying at least 2 separate JVMs?
Peter and I argued that it is sufficient test the contract only in a single JVM, the distributon is part of the implementation, which would need to have its own system tests.
Pretty much the rest of the group was arguing for a more business oriented view, in which a RI should actually provide value. Companies providing the RIs made a sigificant investment into the development and the RI should be more than an academic excercise.
I guess we will have to continue this discussion over time.
Well, I think this meeting was a huge success and should be repeated next year, maybe twice a year as suggested by a few attendees.
As you were...
Now, in October 2008, we actually did meet in Montpellier, France. The hotel 'La Grande Motte' was chosen by Peter as the hosting location and turns out to be an excellent ambiente for this kind of collaboration. We gathered in a small room near the waterfront for 9 to 10 hours a day, only breaking for coffee and lunch every once in a while. Actually, we took our breaks very seriously :-) The food was delicious French cuisine with appetizers and dessert. I probably gained a few pounds during this week.
Work wise, we focused on the most pressing outstanding action items like the OSGi build, their test cases, and of course, my child, RFC 119 - Distributed OSGi. Having David and his colleagues as well as my former Siemens colleagues together in the same room at the same time was very helpful. Siemens committed their RI for the Discovery part and I completed the TCK within the first 2 days. In the meantime, David assembled all of the CXF based RI into a single bundle to make it usable from the OSGi build. I was not able to complete the full TCK, but pretty much everything is there to finish it alone at home in Palo Alto.
We had some very interesting and controversial discussions:
If the RFC claims that it provides for distribution of OSGi services, does the TCK need to verify this claim by deploying at least 2 separate JVMs?
Peter and I argued that it is sufficient test the contract only in a single JVM, the distributon is part of the implementation, which would need to have its own system tests.
Pretty much the rest of the group was arguing for a more business oriented view, in which a RI should actually provide value. Companies providing the RIs made a sigificant investment into the development and the RI should be more than an academic excercise.
I guess we will have to continue this discussion over time.
Well, I think this meeting was a huge success and should be repeated next year, maybe twice a year as suggested by a few attendees.
As you were...
Tuesday, March 25, 2008
Ok, I follow in line
Last week at EclipseCon / OSGi DevCon 2008 all of my colleagues and friends from the OSGi Alliance mentioned their personal blogs. Sometimes they even did not really feel like repeating the information and just referred to it, "oh, I have recently blogged about it, didn't you see that?". No, apparently, I have not. But, I promise, I will follow more closely, now that I have my own ;-)
Right now, I am sitting in the hotel in San Francisco after my first day of Spring Core training class held by Matthew Adams and Daryl Heinz. The first day was not so spectacular as I pretty much know it all already. I finished my labs during the presentation and was rewarded by leaving promptly at the end of the course ;-).
I did learn some interesting things, though. The BeanPostProcessor is a very elegant way of introducing interceptors, but also inject and standard or customized logger to a bean, before it is used. I will try this out in my product code as soon as I get back to work.
Tomorrow, we will go into the details of the DB access layer and the AOP. That should be more interesting.
As the co-chair of the OSGi Enterprise Expert Group I am more interested in the Spring Dynamic Modules project, but that would be another class. Maybe not, since I am working with Adrian Colyer and the other EEG members directly. We (Siemens) have contributed several requirements to Spring DM to make it more useful and a better solution than Declarative Services. DS originally did not cut it for us.
As you were....
Right now, I am sitting in the hotel in San Francisco after my first day of Spring Core training class held by Matthew Adams and Daryl Heinz. The first day was not so spectacular as I pretty much know it all already. I finished my labs during the presentation and was rewarded by leaving promptly at the end of the course ;-).
I did learn some interesting things, though. The BeanPostProcessor is a very elegant way of introducing interceptors, but also inject and standard or customized logger to a bean, before it is used. I will try this out in my product code as soon as I get back to work.
Tomorrow, we will go into the details of the DB access layer and the AOP. That should be more interesting.
As the co-chair of the OSGi Enterprise Expert Group I am more interested in the Spring Dynamic Modules project, but that would be another class. Maybe not, since I am working with Adrian Colyer and the other EEG members directly. We (Siemens) have contributed several requirements to Spring DM to make it more useful and a better solution than Declarative Services. DS originally did not cut it for us.
As you were....
Subscribe to:
Posts (Atom)