Purity or Compromise?

Update August 7: David Bosschaert has started a new OSGi blog for topics related to the EEG direction etc. I recommend every reader of this blog to check it for updates on what's happening at the EEG from here on.

Also a colleague pointed out that my diagram and text below is a bit optimistic about the availability of the Blueprint Container as a development model for Web apps in the near future. The current version of the design (documented in RFC 66) does not actually address this, although a future version is definitely expected to. The current version of the design simply standardizes the deployment of a WAR file onto an OSGi framework, which is a good first step but not the end goal.


This is my last blog as co-chair of the OSGi EEG. In fact as of last Friday David Bosschaert has officially taken over the position. But I was co-chair for last week's face to face meeting in Dublin, so I'll write a bit about what happened.

We have completed the R4.2 Core and Compendium specifications, which were submitted to the 45-day member review July 14. Assuming the vote goes well, publication will be early September. The Compendium includes the new Remote Services and Blueprint Container specifications, and the Core includes several enhancements and extensions resulting primarily from requirements gathered at the enterprise workshop.

That leaves the R4.2 Enterprise Profile, scheduled for release in December, for the EEG to work on. The major part of this work will be mapping various Java EE specifications to OSGi, such as JTA, JMX, JDBC, JNDI, JPA, and last but certainly not least Web apps. The profile will likely also include (by reference) the Blueprint Container and Remote Services parts of the R4.2 compendium.

Enterprise Profile Summary Diagram

I created the diagram to illustrate what we're trying to achieve, and presented it last week to help facilitate the planning part of the meeting to provide context around prioritizing the remaining work (it is not part of any formal OSGi document). Time is getting tight ;-) The OBR continuation is for example looking more like an R5 item at this point.

The main point is that defining a mapping for Web apps (.WAR files) using the Blueprint Container as the development environment and JDBC/JPA for persistence would seem to meet the requirements for a large number of enterprise applications, and represent a good starting point for the initial release of the Java EE mapping work.

What I call "system services" on the side represents the optional use of additional Java EE components (such as transactions, security, directory, and management) that such a Web application might choose to use if it needs them, along with Remote Services for invoking OSGi services deployed in other frameworks.

Because the Java EE components were not designed for OSGi, they depend on mechanisms such as context classloaders and file URLs to instantiate required classes and resources. Which of course breaks fundamental OSGi abstractions, since the framework is responsible for loading classes and managing the access to required resources. We had a very lively debate on the subject of how much the Java EE components should be required to change vs how much the OSGi specification should have to change. We did not reach consensus.

I think the solution may be found in a kind of mapping layer or adapter mechanism (conceptually similar to JCA), like the one in SpringSource dm Server, or in the ServiceMix Kernel (which has been moved to a separate project called Apache Karaf). But all I can really say at this point is that I will be very interested in hearing the results of the ongoing discussion.

Next Monday I start my job as an integration architect for Credit Suisse in New York. And they are not members of the OSGi Alliance - at least not yet ;-)

Thanks to everyone who followed the posts on this blog, and who participated in the discussion. Please keep it going! And support David and Tim and the rest of the EEG members...

R4.2: Next release of OSGi, and what's next

Alex Blewitt posted a great write up to InfoQ of Peter Kriens' recent presentation on the next release of OSGi, which is called R4.2.

This release started in September 2006 with the OSGi Enterprise Workshop. When I volunteered to co-chair the EEG in December I remember being told it would take about two years to get the release out. Pretty close I guess...

The presentation is kind of long (112 minutes), but well worth watching if you're interested in OSGi, or in hearing Peter's view of what's gone wrong with the Java Modularity initiative as currently defined in the JSR 294 community (of which he is a member) and how to fix it.

The new features in R4.2 are spread across the Core and Compendium parts of the , but the major changes in R4.2 are being driven by enterprise requirements, primarily represented in the Remote Services (formerly RFC 119) and Blueprint Container (formerly RFC 124) additions to the Compendium. The new service registry hooks in the core were similarly based on enterprise requirements (specifically from the Remote Services work).

But of course not done with the enterprise requirements. The EEG is meeting again next week, primarily to continue working on the Java EE component mappings Peter briefly references, which we hope to publish at the end of the year in an "Enterprise Profile" document, and start thinking about what's going to be in R5, scheduled for June 2010.

And we need to continue working on application metadata and the OSGi Bundle Repository definitions (despite the fact that Peter doesn't want to define an application ;-). The main reason for this is to provide a better foundation for the kind of development lifecycle tooling commonly used for enterprise application development.

We have made a good start, but there's lots more to do. Meanwhile the debate continues about whether or not it's a good idea to use OSGi for developing enterprise applications directly, or only indirectly through its incorporation in products.

R4.2 represents a significant step in this direction, but we still have a lot to do.

Kill Project Jigsaw Now. Please!

We need to relieve poor Alex Buckley from his suffering. What he is complaining about here is due to the fact that he could not answer the very first (and most important) question put to him by the OSGi expert group: "Why didn't you start with OSGi?"

Furthermore, during that morning's debate, the OSGi members managed to completely invalidate every technical justification for why it's necessary for Project Jigsaw to reinvent OSGi (it clearly isn't).

To be fair, Alex has been put in a very bad position as JSR 294 spec lead. It's widely accepted that modular programming could be improved through extensions to the Java language, and the work in this direction to date on JSR 294 has been well received (with the exception that it has not defined a mapping to OSGi of course). But the problem for JSR 294 going to continue to be that there is no technical reason for mapping to Project Jigsaw instead of OSGi.

It would be so much easier on Alex -- and on all the rest of us interested in Java modularity -- if we could just kill Project Jigsaw. And the sooner the better.

It would also save James Gosling from making further embarassing statements about OSGi. (OSGi is not fat, is not big or bloated, and were Project Jigsaw to live it would have to duplicate most of what's in OSGi anyway.)

There are other good reasons for killing Project Jigsaw. But the main reason is that the OSGi specification already defines a perfectly good, mature, tested, and widely adopted modularity standard. It's been around for more than 10 years, has a JSR and an open process through which the leading Java vendors participate actively (unlike Project Jigsaw), and has gone through several major iterations (R4.2 is very nearly completed as well).

OSGi already has been incorporated successfully into thousands of projects and products, and is endorsed by nearly every Java vendor (including Sun, or should I say at least the part of Sun working on Glassfish).

The industry does not need another Java modularity standard. That's like having two competing alphabets from which to compose words. It just doesn't make sense. It is counterproductive, especially when the IT world needs to focus on reducing cost and improving flexibility. No wonder Alex is pulling his hair out.

The Jigsaw guys had their 15 minutes of fame at Java One. For Alex's sake, and the sake of everyone else involved in Java modularity, let's kill it. Now. Please.

OSGi Standard Questions

In my role as OSGi Enterprise Expert Group co-chair, I get a lot of questions about OSGi. I thought I'd post some of the more interesting ones here.

First, I was very surprised to hear someone from a large end-user organization say that they would be very interested in using OSGi, if only it were a standard.

The OSGi Specification is as much a standard as any specification developed in the Java Community Process, and more than some. I interpret this as what this person's Java EE vendor has been telling them, privately and in confidence of course, about OSGi.

The OSGi Specification started as JSR 8 back in 1999, and the current version (R4.2) is, as previous versions have been, an evolution of the original work, which was formally handed off from the JCP to the OSGi Alliance at the time. Certainly you could say the scope of modularizing Java (which is the essence of the OSGi Specification, after all) is potentially very broad, and you might question whether its entire potential scope has been standardized.

But you can also look at JSR 291 and see that the previous version of the OSGi Specification (R4.1) has already been officially adopted as a Java specification for a dynamic modularity system. The OSGi Alliance is, if anything, more open than the Java Community Process (and yes, I have participated in each, both at the technical level and the board level - in the case of JCP the former IONA rep elected to the EC reported to me).

Sun has never given up its control over the JCP or any specification it chooses to take the lead on. Anyone can join the OSGi Alliance and participate equally in the development of its specification. This is part of what is meaningful about a standard, that its future direction is open for anyone to participate. No vendor wants to invest a lot in implementing a standard that one of your competitors effectively controls the future of. (Thus the current controversy around the JCP and the whole debate about the future of the Java industry, whether it will continue to fragement etc.)

I suspect what this person really meant was "OSGi is not part of Java EE." That is true. But that is not necessarily a bad thing. I mean, having Java EE based on the OSGi Framework would be great. But having the future of OSGi under the control of the JCP, even to the extent of meeting the requirements of becoming part of Java EE, might not be very helpful to it (or to the future of modular programming in Java).

Before I get on to the next obvious question about Project Jigsaw (which you will notice studiously avoids mentioning OSGi), I want to point out that all Java EE vendors have already adopted OSGi, and built their app servers internally on it (well except JBoss, who has sort of tried to bolt OSGi onto their own microkernel, which seems weird). But they are, so far at least, advising against their customers obtaining the same benefits that motivated them to adopt the OSGi programming model internally - apparently including the argument that "OSGi is not a standard." This does not make sense, at least not for the consumers.

AFIAK Project Jigsaw is Sun's latest attempt to re-invent OSGi, or in any case block OSGi or create a substitute they can control. I understand the potential benefits of modularizing the language itself, and I know that the JSR 294 spec lead (Alex Buckley) spent some time liasing with the OSGi EEG (even attending a meeting and taking the abuse, pretty well anyway - I give him credit for trying to do the right thing), and that JSR 294 (which also studiously avoids mentioning OSGi) in theory is not strictly a documentation exercise for whatever they come up with in the OpenJDK project (which by the way is open in the same sense that the JCP is open - meaning it is under Sun's control), and that also in theory the modularity layer is "pluggable." All of this is sort of meant to indicate that OSGi compatibility or mapping is something the Project Jigsaw folks have in mind, if they are not actually working on it (which they are not as far as I can tell, and they also say nothing about this publicly - apparently only when someone brings up the topic of OSGi).

I was not at Java One this year, so I may have the wrong impression sitting remotely as I am, but my understanding is that the Project Jigsaw talks and demos did not mention OSGi. Nor did the descriptions of the plans for Java 7. So the short answer to the question of whether Project Jigsaw is a threat to Java modularity is that yes, it is.

One more thing to add - I have been following the Project Jigsaw public email list, and from what I could gather what was presented at Java One was more or less equivalent to what they could manage to get done by then. And while the demo looked interesting, and certainly seems to prove they got something working, it also is pretty scary when you think how far away that is from what's already available in the OSGi Framework.

Report from OSGi Bundlefest/EEG F2F

Sorry for the delay posting. Here's a report back from the OSGi Bundlefest & EEG face to face held the week of May 11 in Montpellier France.

As some of you may remember, the OSGi Alliance's specification work is aligned with the Eclipse release schedule, since Eclipse Equinox is the reference implementation for the core spec. We had originally been trying to complete our work in time for an end of June publication, to coincide with the release of Equinox.

But we are running into some difficulties - not with the core specification, but with the compendium. In particular, I think it's fair to say that the specification writing phase of the OSGi Alliance process has turned out to be more difficult than anyone expected. In fact the difficulties spilled over into the blogosphere (not that I am trying to reopen the debate about how much change should be allowed or anything!).

The OSGi Alliance is unique among standards organizations and consortia I've contributed to in the past, in part for its informal, collegial environment, but mainly because the Alliance employs a specification editor (currently Peter Kriens) who is responsible for including the member-driven designs into the existing specification.

As a minor refresher, the OSGi Alliance specification development process begins with the formalization of requirements into documents called Request for Proposal (RFPs). When it believes an RFP is complete, the expert group submits it to the requirements group for approval (rarely does an RFP get rejected once an EG submits it - actually this has not happened to the EEG). Once an RFP is approved, one or more solutions to the requirements can be created, in the form of a design document called a Request for Comment (RFC). An RFC has to be approved by the expert group, and once it is, the RFP is submitted to the specification process for finalization.

This last part of the process represents a signficant difference between how the OSGi Alliance works and other bodies work. Especially since the same person has been writing the OSGi specification for about 10 years. The specifications are consistent and very good, as a result. However, most people experienced in standards participation (myself included) find this part of the process takes a little getting used to.

Overall - and I have explicitly asked several other EG members about this - the result of following this step in the process is an improvement over what was in the RFCs. However the RFCs are sometimes the way they are due to compromises among EG members, and the specification process (which is, once again, a good thing) has a tendency to bring things like this back to the surface, especially when the design compromises end up decreasing the quality of the specification. Which, as I've said, has been very good for about a decade now, and we certainly want to preserve the level of quality. On top of all of this, of course, is the fact that OSGi has been around for more than a decade now, and has a very real reference implementation in Equinox, which is used in literally hundreds of products and technologies.

The two designs we are trying very hard to get into the R4.2 Compendium are the Blueprint service (RFC 124) and Remote Services (RFC 119). We had scheduled the bundlefest a while ago to work on RIs and TCKs, on the assumption we'd be done with the majority of the specification work and we could focus on finishing the code bits. Instead, I had to prioritize the specification work ahead of all other work, which created a very ad hoc kind of agenda, one that changed daily - in fact, sometimes several times a day.

At the end of the week we had made some good progress on the specifications - in particular resolving some fairly significant issues that were uncovered - and some of the members also managed to get some coding done. Each day closed with two hour-long calls - one to review the days' discussion for those who were unable to attend (travel budgets are as tight as I've ever seen them), and another to discuss topics still in the requirements or design stage (we are trying to keep the OBR/metadata discussions moving and complete more of the Java EE component mappings in time for the planned end 2009 enterprise profile release).

We have decided to release the core and compendium specifications separately - the R4.2 core specification being implemented by Equinox 3.4 in Eclipse Ganymede released this month - and the compendium needing a bit more time. Currently we are aiming to get it all wrapped up by the end of June for publication in August - fingers crossed.

It was chilly and rainy the whole week, which I suppose was just as well since we had to be in the meeting room all day (except for the famous lunches of course ;-). Saturday was a beautiful day, however, which was lucky for me and for Peter Peshev, since we'd planned to dedicate the day to tourism. We had a great time visiting Pont du Gard, Avignon, and Chateauneuf du Pape - eating cherries bought from roadside stands all the way.

Summary of EEG Provisioning Discussion

During a discussion on Twitter about provisioning OSGi based applications, I mentioned this was a topic of debate at the Enterprise Expert Group and was asked if I could post some details. Because of OSGi Alliance confidentiality rules, it's not possible to publish details. But I can give a general summary.

As I may have mentioned before, one of the biggest gaps we identified in the enterprise release is improved support for the enterprise application development lifecycle (developing, building, testing, deploying, updating etc.). While some of this is going to depend on specific tooling extensions, some aspects are things the EEG can help through standardization. One of those is the OSGi Bundle Repository, otherwise known as RFC 112, which is largely based on the work Richard Hall did with the Oscar Bundle Repository. (It should also be noted that the OSGi Alliance hosts a bundle repository, and that some vendors of OSGi-based infrastructure also provide bundle repositories.)

Before its revival in January, the RFC was last worked on in March, 2006. Meanwhile, the Eclipse P2 project has continued to evolve, addressing much of the same space (and more besides). The current RFC 112 draft was published as one of the early design drafts released for EclipseCon / OSGi DevCon last month.

One challenge the EEG faced was that no one on the EEG knew much, if anything, about what was going on with P2. We understood that we needed to take the P2 work into consideration - this was clearly stated during the OSGi BOF for example, in addition to other community members pointing this out. It was necessary for the EEG to get up to speed on P2, and Pascal Rapicault was kind enough to join the EEG calls and give us a presentation.

What has emerged is a kind of consensus, at least on the approach to the requirements. Here I need to also mention that the normal OSGi Alliance standardization process starts with an RFP, not an RFC. OBR was an exception to this rule, and when questions started to come up about the requirements behind its design, it was necessary for the EEG to take a step back and document the requirements in an RFP we could all agree to. This is basically where we are in the process right now.

During today's call however we got a little closer to returning to the design work. At EclipseCon we announced the schedule for the next release of the OSGi specifications - R4.2. The core is going to be published in June, the compendium in July (adding distributed OSGi and the Spring-inspired Blueprint service), and an enterprise "profile" is scheduled for Q4 (I suppose this means December, realistically) that will contain the various Java EE component mappings. The OBR standard is also targeted for the December release. To get there, as for any other part of the OSGi standard, we have to follow the OSGi Alliance process and ensure everything is approved by the membership and the Board of Directors.

Anyway, where we are in the process is trying to gain consensus around the requirements. The debate is basically over what should be considered in scope for the standard. The most fundamental requirement is to standardize on a repository for bundles and their associated resources, so that someone searching for a particular bundle or set of bundles has a place to find and retrieve them, and in so doing resolve any dependencies they may have among each other and/or to external resources such as configuration files or data resources.

The debate really centers around how much further to go. I think it's fair to say we reached consensus on two items: the layered approach and that the core foundation is the repository. Requirements for additional features and functions on top of the repository are not really considered optional by developers who need tools to assemble, provision, and deploy OSGi-based applications. But this additional level or levels may also not be necessary to standardize. If we do a good job with the core, vendors and open source projects can add on these other capabilities.

One other thing we may want to tackle - and there is another RFP being written about this - is to define an application in the context of an OSGi framework. This is a controversial topic, since we want to avoid enforcing a static style of application definition onto a dynamic framework, but nonetheless seems like it would be useful to help support additional development lifecycle stages, beyond a simple retrieve & resolve.

Questions from today's Webinar on Enterprise OSGi

4/21 Update: The archived Webinar has been posted, and a Webinar on Distributed OSGi scheduled for April 28 with David Bosschaert (one of the design's authors and a developer of the RI at Apache CXF). David is also a good presenter, and I've seen an early draft of the presentation. It looks like it will be very good.

Also a correction to one of the answers below, thanks to Neil Bartlett for that (and apologies for the delay posting the fix).

Eric

----correction---

In this answer, I said that JSR 291 makes OSGi part of Java SE. It does not. The approval of JSR 291 makes OSGi officially part of Java, but not part of Java SE. It would also need to be included in the platform JSR for Java SE for that to be the case. Sorry for the mistake, and thanks again for the correction.

Q: I understand Java 7 includes the osgi f/w, referencing it directly. does that mean that equinox will be part of java 7 SE?
A: First of all, Equinox is the framework implementation, not the specification. Normally the specification is what gets included into a Java edition. But this actually brings up the overall relationship between the JCP and OSGi Alliance. OSGi was started within the JCP as JSR 8 and later the participants decided to split out into an independent activity and formed the Alliance. However, the Alliance retained the rights to evolve JSR8 (OSGi) and propose it back into the JCP, which was done for example in JSR 291, which formally incorporates OSGi R4.1 into Java SE. It's a bit hard to predict what will happen in the future, since things are not completely aligned, but JSR 294 for example is being worked on in close cooperation with the OSGi community. A larger issue exists around this space, for example the controversy over Apache Harmony and their ability to obtain TCKs for certification. Sun has apparently decided to work on Java 7 outside the JCP in the OpenJDK project, which it controls. They have also started something there called Project Jigsaw, and so far that is not good coordination between that modularization effort and the OSGi community. But Sun used OSGi in Glassfish and some other projects, and did a good job of it, too - so perhaps there will be incentive enough over time to bring everything together and ensure the right thing is done for everyone.

----------------original answers-------------

Here are the answers to all the questions we received during today's Webinar on Enterprise OSGi. Thanks to everyone for attending! If anyone has more questions, post them here.

Eric

Several Qs: will the slide set be made available at the end of the presentation ?
A: A recording of the webinar will be posted on the Progress FUSE Web site. Those who requested a copy of the ppt during the presentation will receive a copy directly. Anyone else wishing to receive a copy directly post your email address.

Q: what work is being done to provide support for management tooling?
A: At this point the major activity is mapping JMX to the OSGi framework - this is scheduled to be part of the Java EE mapping profile published in Q4. Otherwise the OSGi framework includes its own management tooling, both command line and API, for installing bundles, starting, stopping bundles etc.

Q: Does Progress want to implement Blueprint based on Felix iPojo?
A: As an integration software supplier, Progress is unlikely to develop its own Blueprint service. However we expect that other vendors will supply an implementation of this specification in addition to SpringSource, who has already announced the intention to implement it. Other alternatives for help in developing OSGi services include OSGi Declarative Services, iPOJO, and Peaberry.

Q: I think that DS should also be part of Enterprise OSGi: It is on par with Spring DM!
A: Yes, thanks for mentioning that, the specifications certainly still include DS as an option.

Q: Is OSGI only for Java based applications? Can it be used for web applications with java based services on the server and javascript based clients?
A: Yes. Here's an example.

Q: Do the core enterprise revisions include work to make RMI work under OSGi frameworks?
A: Basically, yes. The enterprise edition does not require RMI but it is one of the supported distribution software types.

Q: Does the service registry have any relationship to UDDI or any other registry standard?
A: Basically, no. The OSGi service registry is specific to the OSGi framework. However the distributed OSGi design includes a "discovery service" that is intended to allow access to UDDI and other external registry standards such as LDAP and SLP.

Q: When we talk about the OSGI "registry", how does this integrate with runtime endpoint management (distinct from uddi based registries which are yet another topic)"
A: I'm not sure I completely understand the question, but perhaps I can explain the OSGi registry in a way that will help. Every service deployed to the OSGi framework is required to register with OSGi registry - that is how other services find it. The registry was designed for single-JVM use only - as per the previous question we have added extensions for discovering services in the remote case. The OSGi registry is therefore part of every OSGi framework deployment, but extensions were required for it to support remote service invocations using existing distribution software types.

Q: Can this be leveraged for RIA/Ajax web applications to discover services. Especially REST based services.
A: Yes, absolutely. See this example for more information . Regarding REST specifically this is a bit of a work in progress. The background to this topic is the fact that an OSGi service interface is a Java interface today, which implies a synchronous call/return semantic, and is an easier fit with RPC-style distribution software systems. However there has been some work in the area of mapping OSGi to REST-style communication patterns and I actually think this is a better fit for the dynamic environment of an OSGi framework than a communication system that depends on persistent sessions (since a persistent session could be broken by a dynamic service deploy/undeploy operation). I think you will be seeing much more work in this area in the future. Including discovery.

Q: What scripting language(s) are supported?
A: None, directly. The OSGi specification (today at least) is specific to the Java language. However we expect some scripting & dynamic languages & DSLs capable of running in a JVM to support OSGi, for example Scala and Groovy (which SpringSource has said they are already mapping to OSGi).

Q: what are the major pain points of using OSGi technology in the enterprise apps that we need to be aware of?
A: We have talked about some of these, such as the difficulty in migrating existing code (which typically uses different classpath assumptions) and the lack of tooling for the complete development lifecycle. However one of the biggest issues people report back from their experiences is conceptual - that using OSGi requires a different way of thinking about developing applications, and this takes some getting used to.

Q: Can you contrast Distributed OSGi and Jini?
A: Well, first of all we expect Jini to be one of the distribution software systems that will be mapped into OSGi, and there's an example already of Jini used with OSGi in the Paremus Infiniflow product. However, the EEG decided not to standardize on Jini or any other single distribution software type. So while we expect people to use Jini and OSGi together, it is not required. One key difference between Jini and the design of distributed OSGi is that distributed OSGi does not support serializing executable code (which I think is a bad idea anyway because there are some complex problems that I don't think you can really solve - but this is another discussion, I know a lot of people like to do it).

Q: Can we have Eric's email address?
A: You can post yours here and I'll reply or follow me on Twitter ("enewc") to get in touch. (I apologize but I don't like posting the address publicly due to spam.)

Q: Will the distributed connectivity model maintain support for other service binding specifications (namely Declarative Services)?
A: Yes, absolutely. Anything that works with OSGi services is supported since the design extends the OSGi service model itself.

Q: Is remote invocation over HTTP or RMI supported?
A: Yes

Q: Can the transport protocol be customized - e.g. to use ActiveMQ or other MQ?
A: Yes. The design specifically allows for the use of multiple protocols and data formats. One current constraint is the use of the Java interface to invoke a service, which implies a synchronous semantic to the communication. MQ systems can be used currently to implement the request/response message pattern and over time we will be working to create a design to more explicitly support asynchronous messaging.

Q: You mentioned that performance tests will be in place in order the check validity of the implementation. Will performance metrics be part of the upcoming spec and does an implementation have to meet those performance requirements to get certified?
A: Sorry about this misunderstanding - the conformance tests only test conformance to the specifications, they do not measure performance.

Q: Will Progress make available a simple Distributed OSGi Example as a learning start point?
A: Yes, see this example.

Q: How does Distributed OSGI compare to SCA- Service Component Architecture?
A: We reused parts of SCA in the distributed OSGi design since the SCA metadata is abstract from distribution software type, and here we found the two to be very compatible. SCA defines a static component model while OSGi defines a dynamic component model, and here is where the two diverge. But SCA has been successfully mapped onto OSGi frameworks, for example the Apache Tuscany project and Paramus have done this. I expect applications developed using SCA can be deployed onto OSGi without problem - the difference becomes an issue only when using the different programming models.

Q: Are there benefits in using the distributed api across cores on a multi-core machine?
A: I have to say this is a bit of an unknown at the moment. No doubt multi-core architectures are going to have a huge impact on software systems across the board, and on enterprise designs as well, but it's too soon to try to predict how they might impact distributed OSGi (most likely this will occur through the various distribution software types mapped to distributed OSGi though).

Q: How does the Blueprint Service/Component Model relate to the Service Component Architecture (SCA) concept?
A: I actually think they are similar, but the design of SCA includes more of Web services and languages other than Java. SCA is intended to be used for very large, heterogeneous SOA-style applications while the Blueprint Service is specific to the OSGi framework at the moment. Also the Blueprint Service allows explicit development of OSGi services, which SCA does not.

Q: isn't the Distributed OSGi some sort of IIOP/RMI mix that made EJB such a problem in the first place?
A: No, distributed OSGi does not define any particular distribution software type, and has nothing to do with EJBs. In fact the EEG does not include EJB mapping on the current list of Java EE components we're working on. RMI/IIOP is an example of a distribution software system that could be used with distributed OSGi, but distributed OSGi does not require it, or any other specific type of distribution software.

Q: Given that ServiceMix wraps its OSGI runtime and allows for distributed services this way, is there still a need for a distributed OSGI standard?
A: The distributed OSGi standard is not intended as a replacement for an existing solutions. If you're using ServiceMix today for distributed application functionality you don't have to change anything. Distributed OSGi is intended for use with the OSGi service model, so it really only applies to developers interested in using the OSGi service programming model directly (as opposed to indirectly using OSGi through a product) to communicate with other OSGi services in other JVMs, or to external services outside of the OSGi environment. The starting point for distributed OSGi is always an OSGi service.

Q: Which OSGi framework is being used?
A: Any. The OSGi specifications are defined independently of any framework implementation. We expect all of the framework implementations to implement the new versions of the specifications, perhaps not every part, and perhaps not all at the same time, but nothing we do in the EEG is specific to any framework implementation.

Q: Can I deploy more than one module which implements the same service interface ?
A: Yes.

Q: I heard Equinox - would this also be available as part of APache Felix?
A: Yes. I mentioned Equinox several times because it's the reference implementation for the core framework (including for the new R4.2 release) and therefore it will be available at the same time the specifications are published. However we have had the participation of the Apache Felix project lead (Richard Hall) in the EEG since the beginning and I expect Apache Felix to implement the new specifications as well, I just am not aware of the timing.

Q: I understand Java 7 includes the osgi f/w, referencing it directly. does that mean that equinox will be part of java 7 SE?
A: First of all, Equinox is the framework implementation, not the specification. Normally the specification is what gets included into a Java edition. But this actually brings up the overall relationship between the JCP and OSGi Alliance. OSGi was started within the JCP as JSR 8 and later the participants decided to split out into an independent activity and formed the Alliance. However, the Alliance retained the rights to evolve JSR8 (OSGi) and propose it back into the JCP, which was done for example in JSR 291, which formally incorporates OSGi R4.1 into Java SE. It's a bit hard to predict what will happen in the future, since things are not completely aligned, but JSR 294 for example is being worked on in close cooperation with the OSGi community. A larger issue exists around this space, for example the controversy over Apache Harmony and their ability to obtain TCKs for certification. Sun has apparently decided to work on Java 7 outside the JCP in the OpenJDK project, which it controls. They have also started something there called Project Jigsaw, and so far that is not good coordination between that modularization effort and the OSGi community. But Sun used OSGi in Glassfish and some other projects, and did a good job of it, too - so perhaps there will be incentive enough over time to bring everything together and ensure the right thing is done for everyone.

Q: What about standardization? Currently one can provide a certified R4 framework with just the core features. Will there be a certification for the EE features? Are there plans to make this a JSR?
A: No, the plan is to rely upon existing certification for Java EE features, and develop TCKs for OSGi that apply only to the mapping part of the design. In other words, OSGi has no intention to certify Java EE APIs that already have a certification process in place.

Q: Is there any publically available information about JMX integration? (Is that RFC 139? Is *that* available?)
A: Yes, it's in the early draft released last month along with designs for JTA, JNDI, Web apps, distributed OSGi, JDBC, and the Blueprint service.

Q: For web/war support, is there a link to preliminary spec and is work being done on a reference implementation.
A: See the early draft and yes, work is being done by EEG members on a reference implementation, which should be ready later in the year (and no later than publication of the Java EE spec in Q4).

Q: How can I convince our operators to go the extra mile and using a much more complex deployment. Are there any benefits for them?
A: The main benefit for IT operations is the dynamic deployment and management of services and bundles in the OSGi framework. The benefit of using OSGi for service development and deployment is reduced downtime for maintenance updates and upgrades.

Q: Could Spring DM server replace Apache Felix as the OSGi container in FUSE?
A: The answer is no because Spring DM is not a framework - it uses Eclipse Equinox. FUSE works with both Apache Felix and Eclipse Equinox. As far as I know the Spring dm Server works only with the Equinox framework.

Q: Do the connections between OSGi services perform better than JBI connections?
A: This is a little bit of an apples-to-oranges situation and difficult to answer this for sure. Local connections between OSGi services perform very well since they were designed for operation within a single JVM (i.e. no network stack, no serialization of data etc). On the other hand JBI was specifically designed for remote invocation using a normalized message router. When distributed OSGi uses JBI/NMR as a distribution software type (as is basically the
case in SMX/FUSE ESB) I would expect the performance to be exactly the same, or so close it would be hard to tell the difference.

Q: Can you please post the full set of questions with answers at some point?
A: I'm glad you asked (whew)! Yes.