Middleware Matters

Hey Steve. I'm surprised to hear you say that, because I don't know how else one should compare architectural styles except by comparing constraints. Yes, some (all?) RESTful systems are also SOA, but all that's saying is that SOA constraints are mostly (entirely?) a subset of REST's, which doesn't tell you much because SOA doesn't have many constraints, so the same thing could be said for many other styles one might compare it to.

What you really need is to look at the *delta* in constraints, and IMO, generality (of interface) is the primary difference.

Hi Mark, I don't think SOA says anything about interface generality or specificity. All it says is that services present well-defined service interfaces/contracts. There's nothing that says that such interfaces can't also be uniform.

Fully agreed. But as I tried to explain in my last response, I think that's pretty much irrelevant from a comparitive POV.

For the sake of argument, let's say SOA consists of the following constraints; stateless, client/server, layered (which isn't too far from common practice). REST, of course, is a superset of those. So why is it not a good comparison to say that if you added interface generality/uniformity to SOA that you'd get something that would realize more of the benefits of REST than without doing so?

If you phrase it that way, then sure, I'd agree the comparison is fine. I took your original posting to mean that you were saying that SOA didn't allow generalized interfaces but instead required specialized interfaces, but after re-reading it a few times, I think it's just an implication that I read into your posting myself.

But all in all, I don't see SOA as being at the same level as I see REST, which is why I generally object to the comparison. I always say the 'A' in SOA should stand for "approach."

I am not sure that there are any SOA architectural constraints. SOA is a set of document and orchestration specificatons that are only now being reverse-engineered into an architectural style. Opinions seem to differ greatly on what that style is.

For example, Sun are pushing various sets of SOA "Big Rules" that include as core tenets things like "coarse-grained services", "conversational services", "registered and discovered". These are all rules that (depending on your interpretation and emphasis) do not fit the REST model.

I am confident that you could build a SOAP-based REST architecture. I am not confident that you can build an SOA-based REST architecture. You would have to throw away your wsdl. There would only be one wsdl in existence, so registration and discovery are out the window in favour of up-front agreement as far as methods are concerned. You would need to create or bless a content-type specification registry. Your coarse-grained services would need some review to ensure that you weren't interpreting that as a resource with a lot of methods on it. I would also be looking to dispose of or critically analyse any "conversation coordinators" for scalability.

Hi Benjamin, I don't know of anyone who is "reverse engineering" SOA into an architectural style. I mean, there might be marketers or snake oil salesmen out there doing that, but if you start paying attention to anything they do, you're wasting your time.

SOA has been around for many years. It's not a new thing.

I'm not sure you could build a SOA-based REST architecture either. I don't think anyone here claimed that. I said you could build a REST-based SOA.

SOA != WSDL. You can use WSDL to describe services, but you do not need WSDL to create a SOA.

With REST, you still have discovery. That first URL has to come from somewhere, right?

One other thing: over on your blog, you seem to equate SOA with a bus, but that isn't right. It's sad that certain vendors try to market their lame old JMS systems as new-fangled SOA systems, but don't believe for a second that SOA requires a bus. Our Artix product proves this. We categorize it as an ESB purely for marketing purposes, but we actually call it "an extensible ESB" because rather than being a centralized EAI-like bus, it pushes capabilities out to the service endpoints without forcing centralization.