Are SQL Server 2005 Web Services SOA's friend or foe?
I've been reading Rocky Lhotka's posts from today on Remoting, SOA as RPC and Services having tiers. I think he's right about a lot of what he has to say and that got me thinking about SQL Server 2005's Web Services and Service Broker (again).
One of the key points I took out Rocky's first post was that binary formatting of messages was very much the thing to do when you could. Problem: SQL's "ENDPOINT" object doesn't seem to clearly support a method for doing. XML as SOAP, sure, no problem. Then you get an economics question: It is cheaper to build and support something out of the box that uses SOAP or do write an abstractor that implements a data access and data management layer on the end of the wire? I've commonly come across the reason that people want SOAP in the box is to avoid writing more code than they need to and to avoid traffic that a the decoupled design would create.
That's smells like glue again, but it doesn't really have any effect the original SOA friend or fool unless you agree with Rocky (and I'm starting to) that SOA is destined to be implemented as WebServices-Only Architectures (WSOA). If SOA is only implemented as WSOA, then not having binary serialization in SQL Server Web Services is a friendly decision. However, if you're really think SOA as Services without regard to medium or means, then its an unfriendly limitation indeed. Splitting the difference, this becomes one-half a vote for friend and one-half a vote for foe.
In the second posting, Rocky writes:
...This is components-on-the-web. This is COM-on-the-web or CORBA-on-the-web. This is not SOA, this is just RPC redux.
And that’s OK. I have no problem with that necessarily. But since this is the norm, I am pretty much ready to concede that the "Battle of SOA" is lost. SOA has already become just another acronym in the long list of RPC acronyms we've left behind over the decades.
Too bad really, because I found the distributed parallel, loosely coupled, message-based concepts to be extremely interesting and challenging. Hard, and impractical for normal business development, but really ranking high on the geek-cool chart.
Where SQL Server 2005 does answer some parts of this is with Service Broker since that's the problems it address. Except for one. Service Broker is still a SQL Server 2005 to SQL Server 2005 messaging system. While that might seem like a barrier to using them in SOA, realize that you can use the CLR functionality to write Service Programs that are just Web Service Call Wrappers. Then at least you can start using them in WSOA. You can apply the same design had use remoting instead if you like. Naturally, there's going to be limitations and some hard learning to do. So one more half vote for friend and another half-vote for enemy.
In the last post, Rocky makes us think about why SQL Server 2005 Web Services could ultimately be the weakest link in an SOA or WSOA: For all practical purposes, the data access and data management layers merge into a single entity: either the SOAP Endpoint a queue's Service Program. At a purist level, I understand why that's bad. At a pragmatic level, its acceptable if you know the risks and plan accordingly. Still smells like glue to me. There's also going to be a huge temptation to move business logic into that monolith. It'll work up a certain point and many companies will be able to solve the load problem with SQL Server 2005's scale up features. Still, it introduces a finite limitation at a very low level into architecture. When it comes time to "scale out" because you can't "scale up" any longer is when you find out why this wasn't such a good decision and you've found it out the hard way. How this vote counts only you can tell me. For HDR, its not a problem as we're unlikely to develop a system that we couldn't scale up to keep happy. Your mileage may vary.
So does all of this mean that I think SQL Server 2005's SOAP end points and the Service Broker as the engine in an SOA or WSOA is a bad idea? No, but, you have understand that you are trading saving your development time in using it at the possible future expense of having to rewrite it. There are certainly risk management to be done early, and mitigating your rewrite problems the first time is seems like cheap insurance going forward. I would say though that the more informed out are about the issues Rocky brings up, the better decisions you'll make in this space.
For me, the vote remains tied. I see huge potentials for great things in using SOAP endpoints and the service Broker in an SOA/WSOA. At the same time, I see where people could really get themselves into a pickle and a half with it.