Did you already make your arrangements for OSGi DevCon? It is almost 4 weeks before the conference starts and you sure do not want to miss it. Not only do we have a very strong program this year, we also have an OSGi Cloud workshop on Thursday. And, last but I hope not least, it will be the last time to meet me in my role as OSGi Evangelist/Editor/Technical Director/Gopher!
I really hope I will meet most of you on the conference!
Peter Kriens
OSGi Blog
Friday, February 24, 2012
Friday, February 10, 2012
Cloud Workshop During OSGi DevCon/EclipseCon
The OSGi Alliance is organizing a second Cloud workshop during OSGi Devcon! Thursday March 29. The workshop will run from 9am to 1pm. Attendance is free but requires registration.
RFP 133, our document describing the areas we could look into, has matured over the past year. It is clear from this work that OSGi and the cloud are a natural fit. The next stage is working on actual specifications that will make building reliable and robust cloud based systems easier. For this, we need to set priorities.
We will start with a number of presentations from Paremus, JClouds, eBay and RedHat/JBoss about the work that has been done in this area. After this we will move on to a discussion about priorities since we want to start the RFC work.
We have a limited number of places, if you want to attend register quick because there are a limited number of places and we already have quite a list of registrations. Details can be found here.
I will definitely attend the Cloud workshop since it is close to my heart. It will, however, be one of my last activities as the OSGi Technical Director before moving on ...
Peter Kriens
RFP 133, our document describing the areas we could look into, has matured over the past year. It is clear from this work that OSGi and the cloud are a natural fit. The next stage is working on actual specifications that will make building reliable and robust cloud based systems easier. For this, we need to set priorities.
We will start with a number of presentations from Paremus, JClouds, eBay and RedHat/JBoss about the work that has been done in this area. After this we will move on to a discussion about priorities since we want to start the RFC work.
We have a limited number of places, if you want to attend register quick because there are a limited number of places and we already have quite a list of registrations. Details can be found here.
Peter Kriens
Monday, January 23, 2012
Objects Revisited
Alan Kay is the inventor of Smalltalk, the first fully truly object oriented language. I learned Smalltalk in the early eighties and almost everyday that I use Java I am crunching my teeth that James Gosling did not steal more ideas from Smalltalk. About 20 years ago, during an OOPSLA, Alan Kay presented the idea that data should always carry its own methods to access that data. His example was a tape (!) that would contain the data as well as the code to interpret that data.
I think this idea was very much at the core of the Java Management standard first proposed around 1997. Each device would have a Java VM on board and the management system could send little management programs that would be executed on the device. However good it sounded at the time (and I tried to push this idea in Ericsson) the idea never became successful, it was just too complex to make it work reliably on a larger scale where machines have different versions and are implemented in more languages I could ever learn in this life. It was just too complicated, error prone, and risky. Exchanging, or relying on, arbitrary code between loosely coupled machines turned out to be a surprisingly bad idea. Objects, however useful they are in many places, seem to be getting more and more in the way when you build larger distributed systems.
The reason is that objects are so ill suited to go outside their process is that they force the objects to expose their innards, the very thing objects try so hard to hide. Even if we could encapsulate the data during the transition as Alan Kay suggested we would create a huge burden on the receiver to understand (and trust) the code that encapsulates the data. We also created a huge dependency problem that the code provided with the data can actually correctly run on the receiver.
There has always been an impedance mismatch between persistence and object orientation. JPA does a decent job but there is something fishy when you need such huge, complicated, and performance intensive middleware only to simplify the life of the developer. Recently I've been doing some more thinking about this subject and I think that though objects work beautifully in a single process they are ill suited for anything that involves crossing the process boundary, which obviously includes persistence.
Last week during an OSGi EG conference call the problem came up again during the discussion of a specification: do we support serialization for some of the domain objects or not? What is often not realized is that serialization is a public interface since it is shared with the world, it is not an internal implementation detail. This is the essence of modularity, there is an inside and there is an outside. What is on the inside only can be changed what escaped from the inside must be carefully (and thus more expensively) evolved since its dependencies are unknown.
The problem is acute with interface based programming. Two systems running a service defined in interface S (maybe separated in time) that need to communicate their domain objects can only do so if the specification for S defines a serialization format. Putting a serializedVersionUID in an interface is a total waste of bits (although they do occur!). The only solution that I see is that we need to make the marshalling a first class citizen in the contract since the data representation is part of the public API.
However, what format should be used? The standard Java serialization format is quite awkward to parse except for implementation classes.There is good old XML but JSON is increasing in popularity and there are enough other serialization standards out there to fill books. SQL is also a kind of serialization format. Picking one without making others unhappy will be hard.
I've come to the conclusion that the best format is actually ... Java. I started to use what I call data classes. These are classes with only public fields of primitives (or their wrappers), strings, data classes, and collections or arrays of data classes. This subset is very easy to (un)marshal to almost any available marshalling technique using simple rules and reflection. These data classes can act as a very convenient schema for my public interface to other processes, including me in the future (a.k.a. persistence). Since they are part of the Java type system they are easy to use and the compiler can do a lot of sanity type checking. And they can easily be versioned in OSGi.
The data classes are a solution to a problem I see becoming prevalent. It is against pure object orientation but I honestly do not see another solution; The shared code model just does not work very well. Sad, but I think it is time to declare defeat, maybe Java 8 should not steal from Smalltalk but the struct from C?
Peter Kriens
I think this idea was very much at the core of the Java Management standard first proposed around 1997. Each device would have a Java VM on board and the management system could send little management programs that would be executed on the device. However good it sounded at the time (and I tried to push this idea in Ericsson) the idea never became successful, it was just too complex to make it work reliably on a larger scale where machines have different versions and are implemented in more languages I could ever learn in this life. It was just too complicated, error prone, and risky. Exchanging, or relying on, arbitrary code between loosely coupled machines turned out to be a surprisingly bad idea. Objects, however useful they are in many places, seem to be getting more and more in the way when you build larger distributed systems.
The reason is that objects are so ill suited to go outside their process is that they force the objects to expose their innards, the very thing objects try so hard to hide. Even if we could encapsulate the data during the transition as Alan Kay suggested we would create a huge burden on the receiver to understand (and trust) the code that encapsulates the data. We also created a huge dependency problem that the code provided with the data can actually correctly run on the receiver.
There has always been an impedance mismatch between persistence and object orientation. JPA does a decent job but there is something fishy when you need such huge, complicated, and performance intensive middleware only to simplify the life of the developer. Recently I've been doing some more thinking about this subject and I think that though objects work beautifully in a single process they are ill suited for anything that involves crossing the process boundary, which obviously includes persistence.
Last week during an OSGi EG conference call the problem came up again during the discussion of a specification: do we support serialization for some of the domain objects or not? What is often not realized is that serialization is a public interface since it is shared with the world, it is not an internal implementation detail. This is the essence of modularity, there is an inside and there is an outside. What is on the inside only can be changed what escaped from the inside must be carefully (and thus more expensively) evolved since its dependencies are unknown.
The problem is acute with interface based programming. Two systems running a service defined in interface S (maybe separated in time) that need to communicate their domain objects can only do so if the specification for S defines a serialization format. Putting a serializedVersionUID in an interface is a total waste of bits (although they do occur!). The only solution that I see is that we need to make the marshalling a first class citizen in the contract since the data representation is part of the public API.
However, what format should be used? The standard Java serialization format is quite awkward to parse except for implementation classes.There is good old XML but JSON is increasing in popularity and there are enough other serialization standards out there to fill books. SQL is also a kind of serialization format. Picking one without making others unhappy will be hard.
I've come to the conclusion that the best format is actually ... Java. I started to use what I call data classes. These are classes with only public fields of primitives (or their wrappers), strings, data classes, and collections or arrays of data classes. This subset is very easy to (un)marshal to almost any available marshalling technique using simple rules and reflection. These data classes can act as a very convenient schema for my public interface to other processes, including me in the future (a.k.a. persistence). Since they are part of the Java type system they are easy to use and the compiler can do a lot of sanity type checking. And they can easily be versioned in OSGi.
The data classes are a solution to a problem I see becoming prevalent. It is against pure object orientation but I honestly do not see another solution; The shared code model just does not work very well. Sad, but I think it is time to declare defeat, maybe Java 8 should not steal from Smalltalk but the struct from C?
Peter Kriens
Wednesday, January 11, 2012
Java Generics are a Lemon
After working with Java for almost 15 years and deep knowledge of Java generics on the class format level I learned something very basic the really, really hard way. I knew the collections in Java were not that good in comparison what you find in other environments (immutable anyone?) but now I learned that even adding all that extra cruft on my classes is useless when you have a major refactoring.
This week I learned that for the collections and maps the get, remove, containsKey, containsValue, and equals methods do not use the generic type parameter. This means you can call it with any type and you do not get an error if you call it with a type that is not compatible with the generic type of the collection.
I found this out when I changed many Map types to take another key type, expecting that Eclipse would nicely point me out what to change. Well it does not. The puts and parameter calls are nicely pointed out but a significant amount of code fails because it always fails because the object is now no longer found. Fortunately I am saved by having hundreds of solid test cases that tell me where to look.
I understand these methods were not generified because things became too hairy. Why that did not raise concerns about the power of the generics at the time beats me.
Well, guess I learned something.
Peter Kriens
This week I learned that for the collections and maps the get, remove, containsKey, containsValue, and equals methods do not use the generic type parameter. This means you can call it with any type and you do not get an error if you call it with a type that is not compatible with the generic type of the collection.
I found this out when I changed many Map types to take another key type, expecting that Eclipse would nicely point me out what to change. Well it does not. The puts and parameter calls are nicely pointed out but a significant amount of code fails because it always fails because the object is now no longer found. Fortunately I am saved by having hundreds of solid test cases that tell me where to look.
I understand these methods were not generified because things became too hairy. Why that did not raise concerns about the power of the generics at the time beats me.
Well, guess I learned something.
Peter Kriens
Monday, January 2, 2012
Moving On
A bit more than 13 years ago I was asked to go to Linköping, Sweden to help out an Ericsson business unit to get the Java Embedded Server running on their e-box. This single appointment quickly cascaded into an almost full time job managing the OSGi specification process on behalf of Ericsson. In 2001 I switched to the OSGi Alliance to become the Technical Director and in that capacity the editor of the specifications. A hectic decade followed with too much travel, several economic booms and busts, various controversies, working with some really great people, and many rock solid specifications to show for it. When I look at my bookshelf I see a satisfying sight of two shelves with OSGi specifications and books. All said, it was a pretty good decade.
However, it is time to move on. Not because I feel OSGi is not the right answer, on the contrary. I think the OSGi service model is as important as structured programming and object orientation was in the previous decades to increase productivity in the software industry. The reason to leave is that I see a business opportunity in the gap between the mainstream Java developer and where OSGi is today. Working with the myriad of problems around modularity has given me a solid background to ease the transition of existing applications into more modular software. And after a decade of writing specifications creating real systems again looks pretty attractive.
I will stay on until after OSGi DevCon 2012 in Reston, Virginia at the end of March. During that time I will finish the upcoming Core and Enterprise specifications that are currently in the pipeline. After that, well, to find out you have to follow me on Twitter (@pkriens) ...
If you want to show your like what I've done in the OSGi then I would appreciate if you linked with me at LinkedIn and/or provide a recommendation.
Now back to work on my last two OSGi specifications.
Peter Kriens
However, it is time to move on. Not because I feel OSGi is not the right answer, on the contrary. I think the OSGi service model is as important as structured programming and object orientation was in the previous decades to increase productivity in the software industry. The reason to leave is that I see a business opportunity in the gap between the mainstream Java developer and where OSGi is today. Working with the myriad of problems around modularity has given me a solid background to ease the transition of existing applications into more modular software. And after a decade of writing specifications creating real systems again looks pretty attractive.
I will stay on until after OSGi DevCon 2012 in Reston, Virginia at the end of March. During that time I will finish the upcoming Core and Enterprise specifications that are currently in the pipeline. After that, well, to find out you have to follow me on Twitter (@pkriens) ...
If you want to show your like what I've done in the OSGi then I would appreciate if you linked with me at LinkedIn and/or provide a recommendation.
Now back to work on my last two OSGi specifications.
Peter Kriens
Monday, December 12, 2011
OSGi DevCon March 2012, Reston Virginia
After a slow start we suddenly got a lot and very good submissions for the OSGi DevCon 2012 in Reston Virgina. Though this made the life of the program committee harder (thanks to BJ Hargrave (IBM), Neil Bartlett (Paremus), David Bosschaert (JBoss), and Christer Larsson (Makewave)!) it resulted in a fabulous program. There is really no excuse for not visiting this premier OSGi conference in the US considering we're also throwing in a free registration for Agile Connected and EclipseCon which are co-located!
You can find all the submissions here: http://tinyurl.com/osgidevcon2012selections
There really is a lot of interesting stuff:
REGISTRATION FOR THE CONFERENCE IS NOW OPEN.
Registration for OSGi DevCon 2012 and EclipseCon 2012 is open and you should book by Dec 31, 2011 to secure the best price. Employees of OSGi Members are also entitled to an extra discount by using the coupon code: OSGI
If you come for the OSGi DevCon conference please do not forget to check that OSGi is of your interest during the registration since we found out this year that this is actually important for future OSGi DevCons.
Finally, don’t forget to make your hotel reservation too. The conference hotel room booking system for the Hyatt Regency Reston is also available; it is best to book early to secure your place.
Looking forward to seeing you in Reston in March next year!
OSGi DevCon Committee:
You can find all the submissions here: http://tinyurl.com/osgidevcon2012selections
There really is a lot of interesting stuff:
- Apache Felix Web Console - Web Based OSGi Framework Administration — The Apache Felix Web Console has been created out of a need to remotely administer an OSGi Framework. This administration includes maintenance of bundles, editing Configuration, and introspecting ...
- Best Practices for (Enterprise) OSGi applications — Since the first release of the OSGi Enterprise specification in March 2010 the use of OSGi in the enterprise has increased dramatically. Moving traditional Java EE applications to an OSGi stack is...
- Dynamic RIAs with Equinox and Vaadin — When you want to use OSGi on the server-side, there are only a few options when it comes to dynamic and modular UIs. Besides RAP (Rich Ajax Platform), Vaadin is another UI toolkit that integrates...
- Experiences from Building the Fastest OSGi Container on the Planet — What is the fastest OSGi container? Felix or...
- Liberate your components with OSGi services — Converting any large application to be OSGi based is a difficult and complex process. Many projects find the fences that OSGi put in place puts insurmountable barriers in the way of success. Many...
- Mastering OSGi with Ease — This tutorial is a compressed version of the renowned Masterclass on OSGi. Its goal is to take you into areas of OSGi that are extremely useful, but seldom discovered through independent...
- Micro Services in JavaScript — Although modularity concepts from OSGi might not map cleanly to programming languages other than Java, the ideas around OSGi Micro Services might be universally applicable. In this talk we will...
- Moving the Guidewire platform to OSGi — Guidewire Software builds advanced applications for the insurance industry. With over a hundred customers in a dozen countries, including global giants like AXA, Geico, and Tokyo Marine, our...
- OSGi in the cloud - quo vadis? — Modularity as in OSGi solves a major issue with architecting elastic applications for the cloud. Cloud resources are inherently dynamic in their nature and undergo frequent changes either due to...
- Smart Home Mashups: A New Application Opportunity — The number of smart devices in the home is exploding. These devices no longer just include TVs, Bluray players and game consoles. They now include door locks, thermostats, refrigerators, washer...em—
- What's new in the OSGi Enterprise Release 5.0 — The Enterprise OSGi Release 5.0 will be generally available at EclipseCon/OSGiCon 2012. A number of significant enhancements have been made since the previous release, ...
REGISTRATION FOR THE CONFERENCE IS NOW OPEN.
Registration for OSGi DevCon 2012 and EclipseCon 2012 is open and you should book by Dec 31, 2011 to secure the best price. Employees of OSGi Members are also entitled to an extra discount by using the coupon code: OSGI
If you come for the OSGi DevCon conference please do not forget to check that OSGi is of your interest during the registration since we found out this year that this is actually important for future OSGi DevCons.
Finally, don’t forget to make your hotel reservation too. The conference hotel room booking system for the Hyatt Regency Reston is also available; it is best to book early to secure your place.
Looking forward to seeing you in Reston in March next year!
OSGi DevCon Committee:
Peter Kriens(corrected 13/12/2011: left David out of the program committee list)
Mike Francis
Thursday, November 10, 2011
OSGi DevCon Subsmissions, You've Got Until Nov 18!
The submission system for OSGi DevCon was supposed to close tomorrow but as seems customary nowadays the submission time has been extended to serve all those people out there that did not have enough time ... So the deadline is now November 18!
We already have an interesting list of submissions but it would be nice to have a larger set. There are so many issues that seem to generate some controversy that I would expect more pundits. Some topics that seem to scream for the use of the wonderful soap box a presentation at OSGi DevCon is:
- Jigsaw versus OSGi
- Package imports versus Module dependencies
- Manifest first like PDE versus manifest as output like bndtools
- Subsystem versus bundles
- Inversion of Control versus Delegation of Control
- Semantic Versioning
- Relase models
- Extending type safety into the Module system
- Statics versus instances
- Services versus Central control
Of course we also want presentations about experiences (good or bad) or that show interesting products/frameworks based on OSGi.. There is always room and more than enough interest in these presentations.
So given this extra week, you no longer have an excuse not to submit a presentation. Looking at the issues that are currently playing, combined with the enthusiasm of the EclipseCon organization I expect this to become a very good OSGi DevCon/EclipseCon in 2012. You're surely do not want to miss this premier event to interact with the key players in the OSGi eco system.
You can submit here until Nov 18 2012: http://www.eclipsecon.org/2012/submissions-are-open
Hope to see many of you in Reston in March 2012.
Peter Kriens
Subscribe to:
Posts (Atom)