SOAP over JMS

Hey, looks like SOAP really does work over any protocol. Well over JMS anyway (not really a protocol). Saw this here and here. I'm sure all of these vendors (I know Sonic does) provide their own proprietary SOAP to JMS mapping. I suppose there is some value in them mapping it the same way.

The chances of me using this? Zero.

With SonicMQ, however, I have happily used their RESTish HTTP Adapter that just maps destination names into the URL & looks for HTTP Headers for any messaging specifics. Want to check for a message? Check the response queue via a different HTTP GET. Certainly not perfect, but can be useful when working with a technology that does not have a richer client available.

I took a quick scan of this document & remembered a Tim Bray post from last year.

I guess I won’t offer any further commentary on the contents of this document. I can’t help but feel for the H/I/I/M staff who are going to have to do the work, and am reminded of Fritz Lang’s immortal Metropolis, where Maria says: “Nobody cared about the slaves who died laboring to raise the Tower of Babel.”

Not sure if they already are (don't see any of their names listed), but it would be nice if these vendors got involved in AMQP. That seems to have some promise.

Why AMQP? Though many networking protocol needs have been addressed, a large gap exists in common guaranteed-delivery messaging middleware. AMQP fills that gap...

What is AMQP? AMQP enables complete interoperability for messaging middleware, both the networking protocol and the semantics of broker services are defined in AMQP.

AMQP Model The AMQP model explicitly defines the server's semantics because interoperability demands the same semantics for any server implementation.

Wire-level Format To enable technology-neutral interoperability, AMQP defines an efficient wire-level format with modern features.

Simplicity & Integrating with Less Code

I have been on a distributed caching & JavaSpaces kick lately due to the reasons listened here.

I was talking to my co-worker Erik yesterday and we concurred that one of our biggest goals is to come up with an architecture that is as simple as possible and requires the least amount of code.

Coming from my experience with SOA of various flavors and EDA, I have been on many projects that wrote way too much code. The more code the more defects. This is what is so appealing to me about JavaSpaces and potentially distributed caching (e.g., memcached, Tangosol Coherence) (or some of both). In the core of an application it is possible to use these layers as your service orchestration tier as well as your transient data store. This is very appealing as you skip a significant amount of OR and OX mapping which saves heaps of time and defects.

The JavaSpaces API itself is extremely seductive. Lifted from here:

• write: Places one copy of an entry into a space. If called multiple times with the same entry, then multiple copies of the entry are written into the space.
• read: Takes an entry that is used as a template and returns a copy of an object in the space that matches the template. If no matching objects are in the space, then read may wait a user-specified amount of time until a matching entry arrives in the space.
• take: Works like read, except that the matching entry is removed from the space and returned as the result of the take.
• notify: Takes a template and an object and asks the space to notify the object whenever entries that match the template are added to the space. This notification mechanism, which is built on Jini's distributed event model, is useful when you want to interact with a space using a reactive style of programming.
• snapshot: Provides a method of minimizing the serialization that occurs whenever entries or templates are used; you can use snapshot to optimize certain entry usage patterns in your applications. We will cover this method in detail in a later article.

With the addition of JavaSpaces05, there is collection based (i.e., bulk) read, take, and write.

The integration patterns possible with this API are very powerful. Master/Worker, distributed, highly scalable data structures, etc.

It appears that with certain distributed caching vendors, you can achieve some semblence of these patterns, although I am not convinced of that yet, and the associative nature of JavaSpaces (i.e., you use templates containing objects with what you are looking for in a space to find it) is just amazingly seductive.

Love it or hate it, JavaSpaces comes with Jini. To a newbie like myself, Jini takes some getting used to. The whole mobile code bit tends to make people who have lived through J2EE classloader hell nervous. But there are those who say it works fine in Jini. It is a different paradigm and this makes people very nervous.

Maybe what is needed is a mix of J2EE (specifically servlet, JMS, JMX MBeans), distributed caching, and JavaSpaces. Maybe you can use JavaSpaces for both caching and service orchestration. Maybe you should use all of Jini. Maybe there is something else.

From previous lessons learned around persistence in EDA, I am 100% convinced that we need some sort of flexible transient data store (no work in progress database - I beg you!). I see that today as being some form of a persistent distributed cache that requires very little if any mapping code. I also have seen the power of asynchronous integration and SEDA and am not about to give up on it. JavaSpaces and Master/Worker appear to give me that. What other ways are there? Maybe things that I would have considered anathema a year ago like sending objects through JMS for the eventing layer isn't really that awful? I do know that I do not want XML at the core of a brand new system again - again way too many defects with mapping etc. Too slow, too lame. Sure, at the periphery to integrate with services that require it, but never again in the core of the system.

Lots of thinking results in lots of blather . . .

Bottom line, I want this to be as simple as it can be and I want to write as little code as possible. Oh and it should scale like the dickens, be simple to specialize, maintain, etc.