Freigeben über

Is it Service Oriented if the message cannot be intermediated?

  • Artikel

I'm looking at an architectural problem.  I'd love to get feedback.

I'm trying to do two things at once: work on a SOA-based system design, and develop SOA-solutions for other applications to use by working with other teams that are also developing SOA-based solutions.

So, one architect, who I respect and enjoy having rigorous debates with, has suggested that SQL Service Broker is, on its face, a SOA technology.  SSB detects events, sends messages, and reliably insures their delivery to another SQL Server-based system.  It does this by posting information into 'queue' tables, and then, using SQL Server, transferring this information into 'recipient' tables on another SQL Server.  It's an inherently SQL-to-SQL technology.

My opinion is that SSB is part of a SOA, but by itself, it doesn't produce messages that are (a) technology agnostic, and (b) able to be intermediated.  You can use SSB to generate a message, but you'd need to call out to WCF or ASMX or something to actually transmit the message.

It's not a question of whether a message 'needs' to be intermediated. 

I believe that we have message based systems for a purpose, and the purpose is to seperate the caller from the receiver.  If we bind them together in an infrastructure where the message cannot be intercepted, then we have removed one of the key benefits of SOA:

Intermediability: SOA should give us the ability to intercept a message going from point A to point B, and react to that message without informing either end of that pipe. 

In other words, we should be able to introduce an intermediary at any time, without affecting the caller or the sender.  To be clear: We don't have to "inform" either system if their code and configuration remain unchanged.

Technology independence: SOA should also require that I can replace system A with a system of an entirely different technology, and that does not affect system B, as long as the message is consistent.

In both cases, in my humble opinion, passing a message via SQL Service Broker only, from one SQL Server to another, without calling out to WCF or another messaging based mechanism, fails. 

What do you think?  Are these elements (Intermediability and Technology Independence) truly integral to SOA?  Do you believe that we can deliver on the promise of SOA if we back down on either one?

Comments

  • Anonymous
    May 13, 2007
    I don't completely agree on Technology Independence as a basic need of SOA. Though interoperability will be a good to have feature, I guess we can live without it as also if we do have a case of single technology applications in the organization.

  • Anonymous
    May 14, 2007
    The ability to mediate messages is the key to succes of SOA, EDA (and any other messaging system). If not you might be building a nicely working system, the becomes a nightmare to change... http://soa-eda.blogspot.com/2007/04/how-to-mediate-semantics-in-eda.html

  • Anonymous
    May 14, 2007
    The comment has been removed

  • Anonymous
    May 14, 2007
    Hello John, I didn't mean to imply that security of the messages would be breached.  If my paystub information is available to applications A,B, and C, and A sends the data to C, shouldn't B be able to intercept? I agree that complete technology independence is a mythical beast (lots of definitions of Chimera... applying some of them here are quite humorous).   That said, I do not believe that it is wrong to say that many SOA benefits are derived from the reliance on standards.  The communication between two SQL Servers, based on SSB, is not a standard communication.   You cannot observe it.  You cannot route it.  It is completely proprietary.  That is the OPPOSITE of technology independence.  That is technology DEPENDENCE, and that is what I have a problem with.  Any XML-based communication is better.

  • Anonymous
    May 14, 2007
    An architecture without intermediation and interoperability is a lot less of a guarantee of agility and more of an empty promise than what it could or should be (technology independency certainly doesn't guarantee SOA success, but it's a lot more than just another empty promise).  What your colleague suggested sounds like nothing more than the classic "blackboard" architecture pattern.  The pattern can be implemented as a SQL Service Broker, WCF, JMS, WebSphere MQ, SeeBeyond IQ, etc., but why would anybody do that if the easy alternative cleanly separates interface from implementation and allows us to apply routing, policy (John's scenario?), monitoring, and other useful constructs declaratively rather than programatically?  Neither of you is wrong, but introducing an intermediary is a huge step in the right direction.

  • Anonymous
    May 15, 2007
    Nick, A couple of points about SSB and technology dependence (I replied to your other post about intermediation). I used the word chimera for a reason. It's not just a mythical beast. It's a mythical beast made up of parts of different animals. I've seen way too many "technology independent" standards-based systems that were incredibly brittle because they were actually dependent on specific versions of 3 or 4 technologies or standards. Also, SSB is routable (between systems that SQL Server installed, obviously). That means you can even intermediate messages, if you need to. I'm not belittling the benefits of standards-based communication protocols, but there are trade-offs involved and I'm not willing to be as dogmatic as you are about these issues.

  • Anonymous
    May 16, 2007
    Thanks for the credit, John... The ability to intercept messages and understand them is often in direct conflict with security.  Most data-dependent routing systems assume free and total access to the messages they route. That said, most folks on the SSB team historically agree with the need for architectural independence and, to that end, designed the wire protocol to be completely SQL Server agnostic.  This protocol has never been published, but that doesn't mean it couldn't be. Perhaps if enough people asked.....  :) -Gerald Hinson

  • Anonymous
    May 16, 2007
    Hi Gerald, It is good to hear that the SQL team believes in being product agnostic.   The moment a protocol is released, of course, it has a tail on it, because it either has to be supported (e.g. Katmai compatible) or not.  A published protocol is great.  A published protocol that is supported... even better.   A published protocol that has been submitted to a standards body: really great! A published protocol, submitted as a standard, with a reference implementation available for download to allow a non SQL Server machine to collaborate... that's a home run. I know it's asking a lot, but if the SSB team were to take that challenge, I'd encourage you to jump all the way in.  Go for the gold.  Submit the wire protocol to a standards body, and release a reference implementation of a C# app that collaborates with SSB. --- N

  • Anonymous
    May 16, 2007
    The comment has been removed

  • Anonymous
    May 25, 2007
    I see intermediation as an optional feature of SOA, not a requirement. Why should you need another system to be able to act on a message between application A and application B? You may want that flexibility in specific circumstances but not as a hard-and-fast rule... It is useful to have an additional service layer over any application services to increase decoupling (the name of such a service escapes me right now).