Non invasive middleware stage 2: API skins

I think the first stage of non invasive middleware is taking hold right now. Products like ObjectGrid, Hibernate/OpenJPA/EclipseLink, Spring, WebSphere XD, Coherence etc are all there. You can use them with any bodies app server or even JVM. They are all embeddable to various degrees in existing containers or can serve as a container in their own right.

Many people are familiar with skins. Most media players can be reskinned with various themes changing the look of the application. This ability to reskin can also be applied to middleware. People want to be able to use middleware easier than ever before. They want to use it without changing their applications. This means products that mandate a specific API are in trouble. Your own API, even a standard one, means the application may need to change. I'm looking add the capability to reskin ObjectGrid to allow it to be integrated easier in to existing applications.

Examples of possible skins in no particular order for an ObjectGrid type product would be:

• Subset of JPA as a much better cache interface than Maps ever can be.
• JavaSpaces
• JDBC (yep, it's an API)
• REST/WS interfaces to the above
• Various interceptors using XML/annotations to plugin caching transparently.
• HTTP Sessions
• SIP Sessions
• JMS/AMQ
• CommonJ clustered workmanagers

So, I'm going to be examining which ones in the list make most sense and do those first. Obviously, the ones with no APIs look most attractive but other API skins may also make sense.

Comments

[Bill Higgins]

That's interesting. Normally people thing about standard interfaces to allow for varying implementations. You're talking about a given implementation supporting several interfaces!

[Billy]

Well,
It's only easy to plugin if the standard API is the one they are already using and the problem is there are multiple APIs...

[Bill Higgins]

I don't see how your comment relates to my comment :-)

[Sanjeev Karandikar]

Speaking for myself, I would personally give
priority to the following API's specs (at the least so that ObjectGrid is competitive with other offerings in the market)
a) JMS/AMQ - Gigaspaces does have this.
b) Clustered WorkManagers (since Coherence gives this as well).
c) JDBC (I think Isocra's Livestore product does the same thing, except that it is layered over Tangosol Coherence).
d) JPA - I guess if JDBC is implemented over ObjectGrid, then implementing JPA should be trivial enough. I think this gives a competitive advantage over other offerings since neither Gigaspaces/Coherence allows the developer to model in memory caches as relational entities, to the best of my knowledge.
Also Coherence's cache query is more of a simple boolean expression like filter and is not as expressive as SQL/JPA QL (which is inspired by Hibernate QL).
cheers,
Sanjeev.

[CH]

There is a big difference between interacting with Winamp and with enterprise middleware: that there is only one Winamp (with one API which doesn't change often) and dozens (hundreds??) of middleware stacks (with dozens of APIs which change pretty fast due to user demands).
It is far easier to code a Winamp skin and be sure that it will be relevant in the near future than to satisfy all the enterprise middleware stacks. Standardization could push down the number of middleware APIs, but this is a slow process, usually a few years behind user requirements.
So I guess we are stuck with coding to multiple APIs. What I see different today is that we are acknowledging the problems and the costs associated with coding to multiple APIs. Who knows, maybe we will solve this problem as well..