As much as I’d like to see a spec for ESBs, this ain’t it IMHO. James I actually surprised you are all hemped up on this thing. I am a big fan of ActiveMQ – you guys are doing a great job on that.
You must see something I don’t.I
Maybe I do - we've all got different mental models of this stuff. I guess I've worked on these kinds of problems a fair amount & tried many different ways of solving the problem. e.g. many years ago I helped to develop a product called SpiritBroker at a company called SpiritSoft which tried to tackle some of these kinds of issues - then Ross (another ex-SpiritSoftie) built Mule with a fairly similar kind of model & API. I just see JBI as a better model of what we need to create integration solutions - based on a logical XML messaging service bus abstraction using the NMS.
tried to look further past the spec and take a gander at ServiceMix, but if anything that just made me have more of a dislike for JBI.
Part of the problem I think is that JBI is a big spec with a lot of it only relevent to people who make JBI containers or JBI deployment units - which are necessary - but not exactly interesting for developers. So its a little hard to see the wood for the trees.
My best tip is, ignore the container/component stuff & deployment & management. Just focus on the Normalized Message Router APIs
. They are fairly straight forward - much simpler than JMS and they handle various different message exchange patterns rather than just one ways like JMS. (The JavaDoc for this package looks much bigger than it might since there are typesafe interfaces for the different types of MessageExchange).
Basically there's DeliveryChannel, MessageExchange and NormalizedMessage and those are the core APIs of NMR / JBI.
I then figured I’d join the mailing list to get re-educated – but there isn’t one?
Here you go...http://servicemix.org/Mailing+Lists
When I read the spec. and look at your website, nothing leads me to believe that this is not a coupled mess that will lead to anything but angst, misery, and madness for the poor saps that have to use it.The spec says and I’ve heard a couple of the folks that are pimping this thing that this spec isn’t for developers that its for vendors – as if its somehow beneath mere developers:“The primary audience for this specification is system level software engineers who will develop the following: …This specification is not appropriate for application developers or business analysts. It is hoped that this specification will facilitate the development of standard service composition tools and services targeted specifically at this group.”If that isn’t the telltale sign for a failed spec, I don’t know what is.
The first JBI specification is aimed at getting the JBI container and JBI component developers going. I think & hope future JBI specifications (or JSRs maybe) will address ways of plugging in POJOs into JBI in similar ways to Spring and EJB3 happened after the EJB 1 specification.
In ServiceMix we've gone down the road of supporting POJOs using Spring
. I'm sure we can standardize this approach in future JBI specifications.
If “mere” developers look at the spec and get gag reflex, why would they get excited about using it?I don’t know, maybe the impls and some soon to materialize ground swell of support will prove me wrong, but I’m taking it upon myself to set the over under on this thing dying a horrible death at 1 year. Its demise will be worse then EJB.I think that some people (including me) are reacting negatively to it because we all have suffered through years of the mistakes in EJB and when we see something that looks like it might lead to future pain at work we react negatively.
I totally hear you. I've been a long time anti-EJB person myself. Even with the latest EJB3 drafts I still prefer the Spring approach to tell you the truth.
The difference though is, with EJB the hype was all - "this is how you write your business logic" - which caused lots of push back. With JBI folks are saying, application developers keep doing what you're doing - JBI is for those integration companies & tool vendors & EAI type folks to write integration components & containers with. The application developer model will come later if at all (and I'd expect it to be POJO based) - but you can just develop services using Spring / EJB3 and expose them as web services endpoints to join the JBI party.
I don’t think that wonderful things like Spring can save this thing. Sure Spring is great, but that doesn’t do jack for those lovely SOAP errors you are going to get. Or how about a little fun with WSDL? Or a couple dozen javax.jbi.JBIExceptions with a “Not normal enough champ, try again!” errors.James, you said:“How can an API dictate deployment architectures?”I think that is where I am struggling the most. How is this deployed? How does it scale?
However you like :). Put ServiceMix in your WS client and use it like you might use WSIF. Ditto on the server. Or deploy clusters of ServiceMix with ActiveMQ as your load balancing federated network - or use any other communication protocol you like; HTTP with an IP load balancer or another JMS provider (if you really must :) etc.
The first thing I thought I’d see in the spec is this wonderful physical diagram with a million nodes sitting around all over the network. Instead I see this frightening Normalized Message Router in what appears to be 1 JVM.
Rather like with JMS - an NMR could be embedded in a single JVM or it could be a cluster of remote processes on a network. Note that JBI components can be embedded in the JVM or the container can communicate with remote endpoints over different transports.
After that I see 4 different RPC styles:In-Only, Robust In-Only, In-Out, In Optional-OutIs this a spec or a Ron Jeremy film!!??
Its really just modelling the different message interactions you often need to do (and which folks do in JMS already today). e.g. fire and forget one way, one way with acknowledgement, request response etc. JBI's just using the naming conventions in the WSDL 2.0 spec - the concepts have all been around for an extremely long time.
I mean, I know that Sun is on the ropes and I wish them the best, but this is sick sick sick.James, you then go on to say:“JBI assumes an XML service bus and follows the logical model of WSDL. So JBI is designed to work well with WS and WSDL stuff, but equally well with XML over HTTP or XML over JMS or even text & binary data formats over proprietary transport protocols & file polling etc.”Maybe you can set my mind at ease and explain how this works? Let me guess SOAP attachments? Or wait! I get a choice SOAP attachments or Base64 encoding in a CDATA field ?!
The basic idea is a binding component does whatever it needs to do talking to some binary goo - then adapting it to look like a NormalizedMessage in some exchange. A NormalizedMessage is just a bunch of properties (key-value pairs where the value is a POJO) and a blob of XML for the body of the request and optional attachments. How those are physically encoded on a wire or bound to an API is completely up to the binding component to decide.
Then once inside the JBI service bus, you can forget about all that encoding/protocol stuff and work on the normalized message. i.e. JBI uses this API
to mediate stuff to binary/SOAP/REST/CORBA/legacy stuff.
Anyway, sorry to spaz out, good luck – perhaps you’ll prove me wrong.
:) Thanks for a great post Mike!