Christmas 2008
After all the ice and snow, and the people without power for two weeks tomorrow, let's have a great holiday, and good wishes for everyone.
]]>
I've also found a place to move the existing entries in this blog, and have started a new general topic blog as well.
Please be sure to check out both new blogs, whether you are interested in topics related to OSGi, and especially to the enterprise edition of OSGi under development, or whether you are interested in some of the other topics I write about, including interoperability, SOA, middleware, transaction processing, and so on.
Thanks very much to all of you who have followed this blog, bookmarked it on Delicious or elsewhere, and joined the discussion via comments and cross-postings. I feel priviliged to occupy even the small corner of the "blogosphere" I've been able to hold down all these years.
Eric]]>
Just to mention next week's IASA NE meeting at Progress Software, Feb 26 starting at 5 pm, with Hub Vandervoort speaking on event-driven architectures.
Hope to see you there.
Eric]]>
]]>
I've started a new blog called Modular IT on Blogger and will be creating at least the OSGi-related posts there from now on.
Depending on how and when this blog goes away, I'll keep posting other items here until it's clear what is going to happen.
I'd like to thank everyone who read and commented on this blog over the years, and am glad if I have been able to contribute to the "discussion" and to the emergence of this great new medium.
Eric
Update Jan 25: See the new blog for a writeup of the recent OSGi EEG meeting]]>
This is a great free event. I'm Secretary of this new chapter, and our goal is to build up a community of architects in the Boston area. We will continue to have monthly meetings in the Boston area, and hopefully continue to invite good speakers and continue to sponsor discussions on topics of interest. If you'd like to join the Facebook group, please do!
Hope to see you Wednesday evening!]]>
I have mentioned this controversy before, i.e. whether or not the OSGi programming model is likely to become widely adopted in the enterprise. To a large extent this may well depend on how well the EEG does its job. This is one topic I'm hoping to explore during next week's meeting, i.e., which scenarios the release is good for, and which it isn't.
I have also mentioned before that one of the current work items for the OSGi enterprise expert group is adapting various Java EE components to the OSGi Framework. The first priority is to ensure that the components work as they did before, i.e. as if the OSGi Framework were irrelevant. This is the deployment capability, where the OSGi Framework (and by this I mean one of the various implementations of the current specification) is used only to host the application. Such an application could equally be deployed on Tomcat, or a Java EE compliant application server. For this scenario, the EEG work is pretty straightforward. We just have to make sure nothing is broken.
To enable the service model, however the work to map the Java EE components is quite different. For example, perhaps you want to create an OSGi service that uses a Web app as a service, or a JTA-managed transaction as a service. Let's say you want to use JNDI to discover an OSGi service, etc. This will take some effort, and we are running short on time. A critical evaluation point for the enterprise release therefore is whether or not the Java EE components we're mapping are sufficient and/or appropriate.
A recent EEG vote approved four of the design documents in progress (early drafts) to move to the specification (and final) stage: the Blueprint model (based on Spring dm), Distributed OSGi (which I've written about before), JTA, and JMX. Is this enough? Well, perhaps it is for some applications - and probably not for others. What else is needed? JNDI? JPA? JDBC? Web apps?
One great thing about the OSGi standardization process is that it starts by gathering requirements - in fact the initial requirements gathering exercise is what led to the OSGi Board's decision to charter the EEG in the first place. And for any work item pulled from the initial requirements list, the first job was to refine and document the requirements in sufficient detail to create move to the design stage.
Implementations based on the current version of the OSGi specifications seems to gaining momentum: in addition to the several hundred IBM products (I have heard from different IBM sources that the number is between 200 and 300) currently deployed on OSGi, and the plans of all application server vendors to support OSGi based deployments, open source ESBs such as ServiceMix4, OpenESB (BTW this pointer was harder to find than I expected, I am wondering whether pre Project Jigsaw they had more top level info on OSGi?), Carbon, and Mule also support OSGi, or plan to (actually among these it seems Mule is alone in not yet supporting OSGi). And perhaps more interestingly, the Spring dm Server and ServiceMix4 support developers interested in using the OSGi programming model.
Mainly, I think that the enterprise release of OSGi should be about creating enterprise Java applications as a collection of OSGi services. But is the industry really ready to move past the deployment only stage?
Early indications point in the right direction, but I suppose we will have to wait for next year to really find out for sure.
]]>
Christmas 2008
After all the ice and snow, and the people without power for two weeks tomorrow, let's have a great holiday, and good wishes for everyone.
]]>
As you might imagine, one of the hot discussion items was Sun's recent announcement of Project Jigsaw, their latest modularity initiative. Hal, Mirko, Peter, and Neil have already recorded their thoughts in their blogs, and I don't want to repeat what they've already said.
One way I like to sum it up is that it wasn't the breakthrough we were hoping for. After Sun rejoined the OSGi Alliance last year, and announced they were using OSGi in Glassfish, OpenESB, and ProjectFuji - not to mention hiring the Apache Felix project lead - many of us started thinking Sun might finally bury the hatchet. But no, Sun has apparently decided to cooperate with us by competing with us.
We knew, of course, that Sun is kind of schizo about OSGi. I did my best to encourage them to participate in the EEG, and after Sun hired Richard, I guess you could say that sort of happened. But he still is primarily focused on Felix, which is understandable. We have not seen or heard anything from Mark Reinhold and his colleagues, however.
And now we have to worry about the confusion Sun's announcement creates. I can't see the customer or the industry benefit in having to choose between two modularity systems. Do we really expect all the vendors that are currently shipping hundreds of products on the OSGi Framework, to invest in supporting an additional modularity framework for their products, just because Sun proposes it? Yet it is certain to raise questions and generate debate, just as the end is in sight for the OSGi enterprise release.
We have released an updated draft (warning: this is a pdf link) of the current design documents. Several of these have been submitted to expert group vote so that the final phase can begin - writing the specifications. (BTW it's not too late for comments and feedback on the updated drafts.)
You may know that the OSGi Alliance is unique (at least among standards consortia I've worked with) in hiring someone to write all the specifications (Peter Kriens, of course). I think this is one of the reasons the OSGi specifications are so good - and because Peter has been with OSGi since the beginning, he can ensure continuity and consistency.
With any luck, we will be more or less done by March, 2009. I am not exactly sure what the bits and pieces of designs we have add up to yet - I think one of the major work items (in significance if not effort) is to check the current designs against the original requirements, and against several scenarios people are likely to want to use OSGi technology for in the enterprise - such as building web applications, distributing an application's processing work, or managing persistent data.
I want to be sure the release adds up to something, and that it will have the best chance at being adopted. This was, of course, another important discussion item during last week's Board meeting: getting the enterprise release out and ensuring its success.
For me one of the big factors has always been, and still is, whether or not enterprise developers will adopt the OSGi programming model. I am optimistic.
]]>Peter can't believe what Yan is saying... !
In the now usual pattern for a two-day expert group face to face, the first day was given to the core platform expert group (CPEG) and the second day to the enterprise expert group (EEG).
Neither can the rest of us...!
The work to produce the enterprise edition of the OSGi specifications is roughly divided between these two groups, based on whether a particular work item changes the core platform framework itself (CPEG), or to extends the core platform with new features (EEG).
The goal is to complete work on R4.2 in time to deliver compliant software in the Eclipse Ganymede release, scheduled for June 2009. This is because the Eclipse platform, Equinox, is currently the reference implementation of OSGi. However, we have had good participation in the meetings from the other platform providers, including Apache Felix, Prosyst, and sometimes Makewave. It is looking tight, but do-able. And we made some good progress Wed-Thurs last week.
Since I'm EEG co-chair I'll concentrate on that from here on. During Thursday's meeting we pretty much closed out the major design documents: Blueprint Component Model (Spring-"inspired") and Distributed OSGi. The Blueprint, aka Spring/DM (see discussion here) and is nearly complete, just working on the final collection of bugs, most of which have been submitted by Rick McGuire of the Apache Geronimo team, who's developing the conformance test suite (TCK). SpringSource is providing the reference implementation, which has been available for some time in the Spring-DM project.
Needless to say, the Spring mapping document, aka RFC 124 (see Adrian's excellent summary for what it means) is probably the most important work item for the EEG.
Next is probably the Distributed OSGi document, aka RFC 119, which defines extensions for configuring OSGi services to communicate remotely using existing distributed software systems. The RI we recently demo'd for this is hosted at Apache CXF, and David Bosschaert recently posted a Spring-DM update for it. Tibco is working on the TCK, so we are in pretty good shape overall now.
During the afternoon, Yan presented LinkedIn's view of OSGi, including information about their requirements for using it in their next-generation platform. Jan drew pictures on the whiteboard, and used bits of this slideshow. Their major interests are improving the modularity of their applications, and updating them more easily and dynamically. It's great to have a user company participate in the meetings - we could actually use more and I hope more will consider joining.
LinkedIn's Distributed OSGi design
After Yan's presentation we focused on the Java EE mapping work, which has progressed intermittently throughout the past couple of years. It was always a goal of enterprise OSGi to include components of Java EE, but it was not always easy getting everyone to focus on the work and agree on a direction. At the Board meeting in June however, the Java EE work was identified as a priority for the release, and since then we we have been more focused on it and are starting to get somewhere, although significant work remains.
After discussing the topic with others, I believe the priorities are improving the support for Web applications, and for mapping JNDI, JPA, and JDBC. The design docs are in pretty good shape for JTA and JMX, so those are ok. It will be tight, but it looks like we have the right people assigned from Oracle, IBM, and SpringSource to make it happen. Maybe security is also needed...?
Of course, it's easy for me to say the design docs are in pretty good shape now, and that several from CPEG and a few from EEG are ready to move into the formal specification phase, but Peter Kriens actually has to write the specs now, and we will have to see how he gets along...
Place de la Comedie, Montpellier (Peter's home town ;-)
ps on the drive back to the airport, I took a brief detour to Arles, and toured the old Roman town, including the collesium, which is still used, apparently for bullfights (not Christians and lions anymore..)
]]>I just wanted to let everyone in the Boston area know we're having the next meeting of the IASA New England chapter next Thursday, October 2 from 5:00pm-8:00pm at the Microsoft office at 201 Jones Road, Waltham, MA 02451.
I will be talking about why interoperability is so hard, and then Brian Kelly and Yev Bronshteyn will be giving an overview and demo of the new Artix WCF product, which provides native interoperability between WCF and Java.
Click here for an abstract of the presentation and registration information.
Hope to see you there!
]]>This is important because according to OSGi Alliance rules, only members are allowed access to working drafts of documents. This is the first time we've released any of these drafts publicly. As a board member and EEG co-chair, I'm very pleased to see this happen because (a) I often get asked about what's going on and why we can't (in this age of open source) release details of what we're doing and (b) I'm very interested in feedback from the broader OSGi community.
The enterprise edition activity started in January, 2007 with a review of requirements gathered at the enterprise workshop event. Following the OSGi Alliance process, the newly formed enterprise expert group members began writing Request for Proposal (RFP) documents. After an RFP on a particular topic is formally accepted, members can begin writing the Request for Comments (RFC) documents to design solutions to one or more of the RFPs. The early draft contains some of the RFCs that are far enough along to be released - in fact this represents a majority of current work items.
One major work item that is not far enough along, BTW, is the Java EE mapping to OSGi. (Not that I'm trying to put any pressure on any of the members of the group to hurry up and finish their work or anything ;-)
The draft is divided into two major sections, like the work: Core and Enterprise (reflecting requirements taken on by the CPEG and EEG, respectively), pretty much (but not strictly) depending on whether the RFC affects the core, or something mapped to the core.
From here, the RFPs (which I call the design docs) are fed into the formal specification drafting process. So it is a great time to submit your comments (please be sure review the feedback form before you do - this basically defines the IP protections and rights involved).
Of course I am particularly interested in any feedback you may have on the distibuted OSGi document (RFC 119), but you may also be interested in:
It's almost 300 pages, but there's some good stuff there, and 18 months into the task, I think we have a pretty good handle on some things. But then again, maybe not...
The big new areas of course are the distributed OSGi and the "Spring-inspired" component model. And of course, as always, I am very interested in any comments or feedback about the suitability of the OSGi programming model for the enterprise, especially given some of these proposed enhancements.
]]>Computers are after all fundamentally stupid electrical systems that have to be told exactly what to do. At the end of the day, everything is just 1s and 0s - the bit is either on or off. But it is really hard for us humans to work with computers at that level, so we keep trying to make it easier for people to tell computers what to do. Getting the abstraction right is key to developer productivity, but it's a constant struggle. Abstraction layers typically remove flexibility and control from one level in order to simplify things at the next.
Years ago you could hear developers saying they would never use COBOL because it was much too slow and verbose compared to assembler. Yet COBOL remains a very widely used language.
It was not too long ago you heard the same complaint about relational databases - they were just too slow compared to hierarchical and network databases. And don't forget the Web - I remember when we called it the "world wide wait" since it took so long to render a basic page.
In other words, it is sometimes more important to make it easier for people to tell computers what to do than it is to give them complete control. When we introduced high-level "English-like" language abstractions for the the Digital business software product set on VMS in the late 80s (which included an RPC in the ACMS product) we endured constant complaints from developers who wanted more flexibility and control. In those days distributed computing programmers were used to the fine-grained control over remote conversations available in the dominant LU6.2 peer-to-peer protocol.
In fact at the time most transaction processing people thought we were nuts to base a TP monitor on RPC. They thought the only way to do distributed computing was to explicitly program it. We thought it was more important to make the developer's life easier by abstracting the distributed programming steps into what we called the Task Definition Language (TDL). You still knew you were calling a program in another process, but you didn't have to open the channel, establish the session, format the data, check that every send that needed one had a reply, etc. (ACMS is still in production in some pretty demanding environments.)
This afternoon I finally caught up up on Steve Vinoski's recent article and blog entries about the "evils" of RPC. If you aren't already among those who have read them thoroughly, I'd encourage you to. Including the comments, it's one of the best discussions of the merits and demerits of RPC and REST that I've ever seen. The core of his argument is that the RPC abstraction is not helpful - in fact the opposite. Explicit programming is preferable when creating distributed applications.
As someone in the middle of designing another RPC based system (Distributed OSGi), though, I'd like to weigh in with a few thoughts. ;-)
As I've said before, the distributed OSGi design does not really represent a new distributed computing system. The goal of distributed OSGi is to standardize how existing distributed software systems work with OSGi, extending the OSGi programming model to include remote services (today the standard only describes single JVM service invocations).
Because the design center for OSGi services is the Java interface, RPC or request/response systems are a more natural fit than asynchronous messaging. In fact because we are trying to finish up our work this year ;-) we have postponed tackling the requirement for asynchronous communication systems to the next version.
Anyway, after carefully reading the article and blog entries, I believe Steve is not against RPC per se. He wants people to think before just automatically using it because it's convenient. He wants to be sure anyone involved in building a highly scalable, highly distributed system considers the superior approaches of REST and Erlang, which were designed specifically for those kinds of applications. Absolutely no argument there. I am a big proponent of using the right tool for the right job, and RPC is not always the right tool.
In the OSGi work, we acknowledged early on in the process that transparent distribution is a myth. We recognize that constraints may be imposed upon an OSGi service when it is changed from a local service to a remote service, including data type fencing, argument passing semantics, latency characteristics, and exception handling. All of this has been the subject of lively debate, but the benefits of introducing distributed computing through configuration changes to an OSGi framework far outweigh the liabilities.
In our case, therefore, making it easier for OSGi developers to create and deploy distributed services is more important than the loss of flexibility and control available when using local services only. The biggest cost of software development is still human labor, and providing helpful abstractions, incluiding RPC, continues to be an important goal.
This isn't to say anyone should blindly use RPC, or use RPC in place of REST where REST is more appropriate. It is simply saying that ease of use - making it easier for humans to do something like distributed computing - can sometimes be more important than technical concerns such as being too verbose or too slow.
]]>
The number of employees who have both IONA and Progress on their LinkedIn page is probably a couple dozen or even more. We have been neighbors in the Boston area for a long time and there has been a lot of cross-pollination.
Although we have been competing in the ESB and SOA space, we have had a common vision and very similar positioning in the market. It's a bit like two former rivals of the basketball court, each with different strengths and skills, finally getting put on the same team. And it's actually this aspect that's the most interesting - putting together two strong teams with complementary expertise.
I started thinking about this because one of the questions we keep getting on the analyst briefings is how we plan to combing the Artix suite and the Sonic ESB family.
First, it's interesting to note that both companies have been moving away from a "pure" ESB positioning toward a "suite" or "family" of products for SOA. So the question is actually a bit broader: how can we sensibly combine multiple product components and create the best independent and comprehensive "anti-stack" SOA offering?
Some of the specific details are yet to be worked out, but we have always known that even while we were promoting Artix as a unique, configurable microkernel aimed at endpoint integration requirements, the Sonic family's approach, based on leading JMS technology, is something that meets a lot of different and equally important SOA requirements. The Artix suite's focus on distributed service enablement actually adds a lot to the Sonic family, and even as we positioned ourselves competitively in the past I think we each always knew this somehow.
One of the more interesting aspects is the future of the FUSE product line and the view of the combined company toward the open source projects with which we've been involved. We have already seen this commment on the Server Side. As one of the folks who champoined getting involved in open source I am glad to say the Progress folks I've spoken with are very interested and enthusiastic supporters, and see a lot of value in the announced acquisition in helping to get more involved in open source.
We have also worked together as partners. A few years ago we were resellers of the Progress Sonic MQ product, and Artix still offers native integration with Sonic MQ, as does the recently released WCF Connect product. And more recently we had begun integrating the Actional SOA Management product line with the Artix suite and selling them jointly.
A couple of years ago I had the unusual situation of being asked to share a half-day SOA tutorial with someone from Progress. For the first couple of hours we took turns saying exactly the same things about SOA, application architecture, and the unnecessary complexity of Java EE application servers. Then we each took a turn describing how our respective products met the same requirements, and served exactly the same segment of the industry (i.e. SOA infrastructure) with different approaches. Instead of arguing over that, we can now agree 100% and are part of the same team.
]]>
"Demo Dolly" David Explains Distributed OSGi Demo
The goal of distributed OSGi is to extend the OSGi framework for distributed computing capabilities by configuring an existing distributed computing software system (such as Web services, CORBA, or Eclipse ECF) behind an OSGi service. The demo showed a Web services solution using Apache CXF as the distribution software, but the design should work with any distributed computing system.
The demo used Apache Felix for the OSGi framework and shows the configuration and publication of a remote OSGi service and uses CXF facilities to generate a WSDL file and consumer and provider proxies for the service.
The goal of distributed OSGi is to allow a service running in one OSGi framework to invoke a service running in another, potentially remote, OSGi framework (meaning a framework in a JVM). Today the OSGi standard defines how services talk to each other only within a single JVM. Extensions are needed to allow services to talk with each other across multiple JVMs - thus the requirements for distributed OSGi on which the design is based.
We did not want to invent a new distributed computing system, since so many already exist. (In fact we had pretty strong feedback on that point!) The design introduces some new OSGi properties to identify a service as remote and a discovery service through which a local service can find a remote service and obtain the metadata necessary to interact with that remote service. The design is intended to support any communication protocol and data format (with some constraints of course, having to do with the use of Java request/response interfaces as the service contract). Another goal of the design is to allow services in an OSGi framework to interact with services external to OSGi, both as client and server.
The design uses SCA intents to express a service's capabilities, and a requester can use these intents as a filter to help discover services with the required capabilities (e.g. security or reliability).
Overall we recieved good feedback, and a lot of questions pertaining to work that still needs to be done. We hope to be able to publish the code to Apache and publish a draft of the design doc this summer, perhaps in August, after we have a chance to formally review the initial implementation with the EEG membership, and get their blessing (no doubt there will be some changes as well since this is just the start).
]]>