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.
8 years ago
Posts
Hi Eric,
ReplyDeleteI just came across this post now. I'm curious why you claim SCA is a "static component model". For example, re-wiring services and reinjection for Java implementations is supported. In addition, an SCA domain can be a very dynamic thing, with services being deployed and undeployed (which is how we implemented it in Fabric3).
A more general question I have is wouldn't it make sense for Distributed OSGi to start with the OASIS SCA specifications instead of taking parts and creating a new distributed component model? This could be done by creating a separate specification that defines SCA integration with OSGi.
Hi Jim,
ReplyDeleteThe OSGi framework supports dynamic discovery as well as dynamic wiring. In other words, you can start with a service consumer that doesn't have any idea of the provider it's going to access, and dynamically discover and instantatiate that service. This is more dynamic behavior than SCA support. However of course SCA can also map to OSGi, and in that case inherit some of this dynamic behavior. At the EEG we have been waiting a long time now for someone to pick up this work and complete the definition of how to map SCA to OSGi. This work was started a long time ago but more or less abandoned.
WIth regard to why we don't start with SCA, one important factor is that we did not standardize on any single type of distribution software (we had a suggestion to standardize on JINI for example) and we did not want to restrict the design to SCA compliant software since it is not widely adopted and implemented. Maybe it will be one day but when we were doing this work the OASIS specifications were not completed.
I should note that we have had representation from SCA folks in the EEG nearly from the beginning, and we have incorporated SCA intents into the basic design, and defined SCA metadata as a supported type.
Personally speaking, as someone who has also worked on SCA, I spent a good bit of time trying to encourage folks from the SCA community to complete the specification defining SCA mapping to OSGi, but since expert groups rely on "volunteer" labor it is not something I have any ability to enforce. Perhaps someone will pickup this work for the next release.
Eric
Hi Eric,
ReplyDeleteI'm not sure I follow how SCA does not address the needs you stated above. In terms of dynamism, SCA does allow dynamic discovery in that wiring can be done after a client has been deployed and instantiated. For example, wiring could be performed sometime after a client has been instantiated when a service provider becomes available. Or, a client can require a multiplicity of services which can be updated as providers come and go. Both of these can be done explicitly by a deployer specifying a target endpoint or by the runtime through some programmatic mechanism via autowire.
I have a feeling I am not understanding your dynamism requirement completely. Could you provide a specific example?
I am also not sure I follow the requirement around distribution software. By distribution software, I'm assuming it to be a remote transport/protocol. Or does this also include some type of inter-runtime discovery and communication? In either case, SCA doesn't mandate anything. Actually to be "compliant" I beleive SCA requires support of Web Services but there is nothing in the SCA specifications that tie it to Web Services. A completely functional SCA runtime would not have to make use of Web Services.
I am aware of the fact that SCA people were involved in the distributed OSGi initiative. I also believe some of them recommended using SCA in the manner that I outlined. Now that the SCA specifications are in public review at OASIS, wouldn't it be a good idea to reuse that work instead of duplicating it? This would provide end-users a common way of building distributed applications that works accross different runtime environments (OSGi and non-OSGi) as opposed to fragmenting the standards space.
I'd potentially be interested in helping with the mappings from SCA to OSGi. Some of this has actually been done as part of the SCA Java specification. In particular, SCA Java has officially adopted OSGi classloading semantics for making Java artifacts visible across contributions (the SCA deployment unit). I believe the amount of additional mapping work would involve several things. First, support for OSGi bundles as an official contribution format. Second, an OSGi binding that exported SCA services to the OSGi service registry and allowed SCA components to consume OSGi services. I'm pretty confident most of this is relatively straightforward work as we have implemented OSGi classloading and bundle support in Fabric3.
In my opinion, JEE has become way too complicated for building distributed applications. It also doesn't address many important requirements concerning modularity and asynchrony that go along with creating distributed applications. I think it is important to avoid fragmentation moving forward as replacement technologies emerge in this space.
Hi Jim,
ReplyDeleteI understand SCA has the capability to dynamically wire clients to servers, but I believe SCA requires the servers to be deployed for this to happen. OSGi also allows the server deployment to be dynamic when a client requests a server.
Further SCA work is definitely being proposed for the next version of OSGi, and hopefully someone will pick up the mapping work that was not completed. In fact one OSGi member has already indicated an intention to do so. The current release is nearly finished - we are on a tight deadline now in fact to finish the specs.
I know of three publicly available implementations of distributed OSGi - a subproject of CXF, Eclipse ECF, and Tuscany. CXF and ECF do not use SCA, but Tuscany does. So I think the design accommodates both folks like yourself who are interested in SCA, and others who are not.
Eric