User Apathy in the Air

I just flew from Newark to Boston and was amazed by the percentage of passengers who were content with watching 30 minutes of repetitive commercials 12 inches from their face.

The United (now Continental?) flight offered a free preview of the in-flight directv service. Having ESPN feeding me the latest NHL and NBA playoff news during the normally tedious boarding process and ascent was an unexpected delight, tiding my ADD mind over until I was allowed to power on my iPhone. However, shortly after the preview ended (and the plea for $ to continue viewing began), I shut down the display.

Twenty minutes later I noticed that everyone else still had their displays on, still watching the directv advertisements flash before their eyes. This got me wondering... are consumers really so lazy that they would rather watch an endless (and repeating) stream of bad commercials rather than figure out how to turn off the screen?  Or are they too dumb to realize that you can even turn it off?  Try to make a guess...then look at this photo of the controller:

Where's the power button?

I wonder if "no power button" was an explicit decision from the airline/directv execs...some kind of sneaky ploy to make more money from having more eyeballs on more commercials.  What do you think?

I guess that isn't too likely, since it fails to pass the most important test in human behavior reasoning:
Hanlon's razor - Never attribute to malice that which is adequately explained by stupidity.

HIT ME

This was an old update that I wrote for my boss.  I wrote it with as many acronyms and identifiers as possible just to test her :-)
Is everyone forced to work with this many TLA or is it just me?


The Stepstone project's transition from the SODA subproject of Eclipse OHF (moving to RT) to OHT is almost complete. We have been working on support for the ISO/IEEE P11073-20601 PAN protocol and are slowly adding support for the various 11073-104xx specializations. Most of this support involves generating the java class model from the ASN.1 model and adding support for the MDER encoding.

We have also began work on a WAN interface prototype using WS-I Basic (SOAP/HTTP with WS-Addressing) to send the XER encoded ASN.1 event reports from the AHD to the RMS (WAN Device). As part of this work, we have analyzed some other web service standards including WS-RX (WS-RM and WS-MC), WS-Event/WS-Notification, WS-Man/WSDM, and others.

One alternative being discussed in Continua is the re-purposing of the IHE PCD protocol (HL7 V2.5 over MLLP--a TCP/IP protocol with some extra framing characters)

Once the data arrives, it is up to the RMS to translate these messages from the IEEE DIM model to HL7 RIM in order to generate a CDA-based PHM (CCHIT approved?) and convert the IEEE nomenclature to the various medical nomenclature standards like SNOMED or LOINC. Once this is complete, the PHM is sent over the xHR (x=PHR, EHR, EMR, etc) interface using IHE XDR or XDM (both from the XDS family). If XDS is used instead, such as across a RHIO or HIE, we will have to deal with handling patient IDs through profiles like IHE PIX/PDQ.

This Just In: Enterprise OSGi Too Messy

wab, eba, application.xml, ...

Why do we need to introduce all of these new concepts? One of the reasons OSGi feels so much nicer than the traditional J2EE stack is that the number of concepts is vastly reduced. The core is kept to the minimal set of concepts to achieve the properties of modularity, dynamicity, and security. When I create a plug-in project in eclipse, there is only one meta-data file, MANIFEST.MF, that I need to worry about.

Compare this to a J2EE project which introduces so many files and descriptors in my project that the IDE designers decided they need to hide them from me to make it 'usable'.

Evil Will Always Win

Facebook just enabled a 'smart lists' feature to help build out their understanding of you and your connections. Certain lists (eg. family) add a profile suggestion for everyone that you add to the list. As a result, I have been bombarded with many family confirmations from fairly distant relatives.

This is a fairly sneaky way to get more information about their users without each user needing to enter stuff...because everyone has that one crazy relative that spends way too much time on facebook, tagging you in all your own photos, and filling out lots of extra relationship details just for you to 'confirm'. Its thinking like this that will keep them ahead of competitors like Google who can't seem to crack the "social" nut, I guess. Its like in spaceballs:
Anyway, in this case I really would like to acknowledge the relationship, but the exact relationship is not defined on the dropdown box (there's no such thing as a 2nd-cousin-in-law). So, it seems the system will not let me confirm a relationship exists without picking exactly what that relationship is (for which there is no option). Dear Facebook, please provide a 'write-in', 'other', or 'unspecified' option to these confirmation dialogs...I feel bad hitting the 'ignore' button like this.

If you can't beat 'em...

One of the things I consider most strange about commercially-tied open source projects is the lack of co-opetition.

Why do we need separate Apache projects for Axis2 and CXF?
Well that's because IBM and WSO2 'run' Axis2 while CXF is backed by Progress Software.

Why do we need OpenJPA? Why not just storm (I mean collaborate within) the EclipseLink project?

Its amazing to me how many open source projects have only a single company's backing. What happens when that company deinvests? I think organizations like Apache and the Eclipse Foundation work hard to get these players to see the light and work hand-in-hand on a common code base (for the good of the community), but I guess its somewhat against the open source ethos of letting "a thousand flowers bloom".

Maybe it has something to do with whether the companies involved are market leaders or not. Second and third tier companies have the most incentive to collaborate. If you're not the market leader, its in your best interest to band together to 'defeat' (or at least compete with) a common enemy. And open source is the perfect place to do that.

So Long and Thanks For All The Fish

Glassfish, MySQL, and the whole "aquarium".

Goodbye Sun.

Nested Frameworks and the Scoped Service Registry

From Peter Kriens' great blog post, http://www.osgi.org/blog/2010/01/nested-frameworks.html: Nested frameworks, or the ability to run an OSGi application entirely within the boundary of a host OSGi framework, "will likely appear in a future OSGi specification".

Some more excepts from the post:

"I do not believe that the Application Server model where a number of WAR files are running in the same VM should be followed by an OSGi model where these WAR files are running in an OSGi framework only sharing their dependencies. Though it is good to manage a dependency (as OSGi does), it is best to not have a dependency in the first place. It is good to handle multiple versions of the same library but the problems caused by multiple versions quickly cascades to umanageable proportions.

I therefore believe that the original model promoted by OSGi, where the application emerges from the installed bundles, is still by far the best model we have. In this model bundles adapt to each other and collaborate with each other through services; exporting implementation classes is an anathema in this model."

"Any services in the service registry are available to all bundles because the framework is the application."

"This model raises the question how to handle multiple independent applications. Do they all require their own framework? The answer is an unequivocal yes!"


Now my thoughts:
An application does not an island make.  Today's applications are collaborative and connected. This makes defining application "boundaries" tricky. Is an application the main process running on a particular system, or is it the collection of all the related processes running on potentially multiple nodes across the network?

Its pretty clear that one could group all compile dependencies (i.e. bundle and package dependencies) together and call that an "app", but what about the service dependencies? What about the optional service dependencies? How do we give applications the isolation they need, allowing them to have private services that are internal to their boundaries, while still allowing them to share/use services to/from the wider community.  It would be silly that this would need to go through some kind of remoting infrastructure if the same applications are running on the same instance of the same JVM.

Even within the same application, one of the things I've stuggled with in OSGi is how to get bundle granularity right. You can build a highly modular application where each bundle contains only a few classes and offers only a single service or two...or you can combine like bundles into "cohesive" units which offer a larger number of related services. Loose coupling/high cohesion is well and good, but when rubber hits road, its always grey. A scoped service registry would allow you to mix and match your highly granular bundles into a more consumable chunk (like Eclipse features) by defining a way to register semi-private services that are only visible to other bundles within the same scope.

Unlike the song from Paul Simon, an application is neither a rock nor an island. Applications are becoming more entwined and I think this is a fundamental consequence of our industry's shift towards SOA.

The nested frameworks spec seems like step in the right direction, but I can't help but feel its a bit over-complicated.  Maybe we'd be better off just introducing the notion of a scoped service registry where we can control the visibility of services between arbitrary groups of bundles?