Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

Is it Service Oriented if the message cannot be intermediated?

Is it Service Oriented if the message cannot be intermediated?

  • Comments 10

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?

 

  • 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.

  • 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

  • Nick,

    You are definitely wrong on this one. First, intermediability is not a requirement of SOA. In fact, for some applications it is prohibited. For example, would you like me to intercept the message containing your current paystub without your bank or Microsoft knowing about it? I didn't think so.

    Second, complete technology independence is a chimera. While I would agree that your SOA should limit the amount of technological coupling, every application is different and has to be designed according to its unique requirements. There is some subset of applications for which a dependence on SQL Server is a reasonable trade-off for the benefits gained.

    With all that being said, I agree that the best place for SSB is "under the covers" (hidden from individual applications). I'm in the midst of designing an integration system built on top of SSB that insulates the applications from any knowledge of SSB. In that way, I hope to get all the goodness* of SSB while shielding application developers from its butt-ugly interface.

    *Just in case somebody comes across this by googling, I have done a complete 180 on SSB. I no longer consider it an abomination. You can blame Gerald Hinson for changing my mind.

  • 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.

  • 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.

  • 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.

  • 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

  • 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

  • Hi John,

    That's what I hate about the 'cutting edge.'  Too many folks jump up to say that they NEED some feature of the latest and greatest version of something or other.  

    I'm a fan of stable standards myself.  

    As for routable between SQL Servers... it is still routing on a non-standard, non-observable protocol.  If I want something hidden and obtuse, I'd use CORBA.  ;-)

    I came out of a meeting today with a brilliant architect working in the MSN team.  We were discussing data routed protocols... really elegant stuff.  

    And at the heart of it: single, simple, standard mechanism.

    There is power there.  This is not dogma.  This is a willingness to consider the realy strength that comes from simplicity.

  • 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).

Page 1 of 1 (10 items)