Thursday, February 03, 2005 - Posts
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.
RebelGeekz offers up ideas for XML 2.0 that's been running on a background thread for me all day. I've really been trying to see value in my world for what he's proposed in response to Mike Champion's query for XML 2.0 ideas.
Rephrasing what's been proposed as I understand it:
- Some percentage of the information represent in XML is an object, the rest is tabular data.
- The expression of tabular data shouldn't be sequences of nodes but should be delimited lists.
- The “cruel reality” is that data is “square shaped.“
- This somehow yields “relational XML.“
The more I think about what's being said here, the more Good Old Spongebob comes to mind. No, I'm not calling the RebelGeekz a Spongebob. But this doesn't feel like “Relational XML” as I'd want to see it.
First, I don't think the there's just two models for data in XML. I agree that there's certainly an object graphs and tables uses for XML. But there's also a couple of others: hierarchical and what I'll call “relational.” If you go with definition of an object graph as a directional graph of objects, it seems to be that you'll run problems where one object contains instances of its own type. But we do that kind of stuff all the time: consider the XML representation of an organizational chart, where any <person> might contain a broad-and-deep collection of children elements also of <person>. That's not a direct graph at all (at least as I learned ages ago) -- but it is a simple, recursive hierarchy. We've also learned from the database world that its not such a good idea to have multiple instances which represent a distinct entity in the same schema (i.e., the goal of normalization is to minimize repeated instances by replacing them with references to a single instance within the schema.) So to really be “relational XML” (albeit somewhat primitive by comparison in a relational sense to what an RDBMS can do) all we need is what we have: ID and IDREF.
So while I agree that there are certainly cases where XML is used to express tabular data, I'd rather term such instances as Tabular or Structured XML, where all of the data “lives in rectangles“ joined together “under a tree.“ thus: “Spongebob Squaredata.“ Not-so-squarely-but-regularly-patterned data might then be called -- continuing the analogy -- Patrick Starfishdata. What about the data that's somewhat regularly shaped but primarily just refers to other data to achieve semantic value? Wow, that's hard because Scobel isn't in the show. Eugune Krabdata maybe? The chaotic structure of XML in document form? Jellyfishdata maybe? But I digress... My point is that just viewing XML as only using used to represent only object graphs and tabular data isn't accurate since it leaves out significant use cases. If there is a cruel reality then, it is that while Spongebob Squaredata might be the star of the show, there's others on the set (or on the cell, I guess, since we're talking about Animation afterall...) that play a part. Since any of them may need to be transmitted over the wire, though, it doesn't make sense to have different compaction or compression method for each.
Seems to me that its this compaction that point number goes after. I have two problems with it. First, we already have attributes that can achieve some compaction, so why not use them. Secondly, the majority of the schema that exist today require an explicit qualified name for an entity. With what's suggested here, I'm left guessing that the first <row> of a family is essentially a list of qualified names for the tuples in the subsequent rows. How would you actually indicate that with a schema though? And how exactly, with schema as we know it today, would you describe the tabular data is since the meta data occupies the same space? I think that would hard, and it would certainly cause a lot of semantic reinvention in the schema space. How do you'd even begin to do transformation, query and modification on data in XML leaves me dumbfounded. Considering you can already achieve significant compaction today with attributes instead of elements whilst retaining the full power of Schema, XPath, XSLT and XQuery, I really wonder if that's not the best choice going forward.
Again, I'm not against compaction or compression of the XML infoset -- that we need. I do think there's better ways to get it though: ones that don't complicate or compromise the existing tool set for working with XML. I think a better way to accomplish it would to have some sort of streaming compression encoding option for XML. Let's face it: Microsoft and others have great algorithms and tools for doing that already, they've just not been applied to this problem. Heck, you probably don't even need to go that far... couldn't you just bzip2 the payload? That could really shrink XML down to size without altering impairing the higher level tool set's ability to work with it.
Just like SpongeBob is still a Sponge: Porous, Absorbent and Yellow, let's not let our desire to make XML more wire-friendly just to have it drop to the deck flop like fish. Keep it simple, machine parsible and “toolable” by what we've already invested in.
After a long break,
Alter View Create Function is returning to
SSWUG.ORG on February 15th with a two-part series on Cryptography in SQL Server 2005.
I need to vent...
I'm a geek and my people skills aren't really where I'd like them to be. Even so, there's some basics that I've learned the hard way over the years that I wanted to share. Found myself today on the verge of imposing these thoughts on others from the TRWISMW frame of mind because somebody else was in that mode with me.
TIMTOWTDI: There's More Than One Way to Do It. The kind of pragmatism I've come to deeply respect about Perl. I've actually found that most of the best IT folks actually embrace and embody this. It just lets you work.
BYWITWW: But Your Way Is The Wrong Way. There's some folks though that always seem to have to be right, to have to win or thinking their showing leadership by having to “group discover” and prove correctness this whilst tearing down others ideas and works. I can tolerate the first, understand the second but the third behavior needs to be saved teaching or coaching, not leading or managing. Whenever I see a Holy War about a language, platform, technology or even something really important -- like how to brew beer -- I have to wonder if both sides aren't guilty of this.
So what do you do with a BYWITWWer? Well, those folks who can't be wrong are easiest to deal with. Let them be right, at least in their own minds. The rest of us know the score. The folks that have to “win“ really just need to go Seven Habits training (or need a reinforcement about “Emotional Bank Accounts“) to “get it“ and move on. The last group, its just best to let them go until their done with doing what they feel they must do. Then you can have a more reasonable conversation with them.
TRWISMW: The Right Way Is My Way. When people -- particularly people in leadership roles -- go into this mode, they've totally lost me.In a sense, this is an extreme form of the last type of BYWITWW. People who get into this mode seem to have a death grip on their idea so badly that they have to wield like a rod to smite down those who disagree with them about the topic. Its ugly, its wasteful and its completely counter-productive.
So what do you when somebody goes into TRWISMW mode? Concede. Acknowledge their obviously superior point start planning your exit strategy. There's nothing more to be gained from the exchange for either party.
What do you think? How do you deal with the BYWITWWs and TRWISMWers? After all... TIMTOWTDI
I'm getting cranky today because I'm trying figure out the behavior of some code that's NIH but I have to support. I'm not having much luck because I can't reproduce the root error that's causing my error handling stuff to work right. Starting to get frustrated, I decided to take an actual lunch break and do something refreshing: read.
And what was at the top of my reading stack?
Test-Driven Development in Microsoft.NET.
Wow, I'm thinking reading the section on "Simple Design." If there is a trick to writing sustainable code -- and I'm not saying that there is -- this section just laid it out wonderfully, with my paraphrasing:
- Write code so that's appropriate to the folks who will be following behind you. Writing code that only can maintain isn't maintainable. Writing "guru code" only works for organzations that have them. Good Code isn't Moon in a Dewdrop, it should be Zen Mind, Beginners Mind.
- Write code that passes all the tests -- and have tests that "pass" when the code "fails as expected."
- Write code that communicates everything it needs to. That's much harder than it sounds because, as developers, we tend to assume a lot about what a person looking at the code knows about both the problem and technology domains. That's a problem for sustainable designs because the problem domain is much harder to grasp, and because of that, its much harder to document well. But frequently, mapping problem domain concepts to the code is only way to understand why somebody wrote what they did.
- Write the smallest amount of "decorative code" possible, ideally none. The book actually says "the smallest number of classes and methods" but I think it applies more generally. I'm bad at this because I tend to like to build code today anticipating future uses. But there's a different problem too: code that's written in a more complex way than the problem domain justifies. I recently got (rightfully) dinged in a code review for using an Interface pattern to a problem when its likely that we'll never really need more than just way to do the work at hand. That's a practice because it introduces unjustified complexity into understanding the code for the sake of making it fancier. Of course, if you don't push on things, you never learn them. Hard to decide how to balance that. On the database design side its very easy to go the extreme version of this with normalization. I can't tell you how many designs I've been part of that were either so overly normalized that they became nightmares to work with or so poorly normalized that they couldn't be sustained. Non-sustainable database designs create way more hard and expensive problems than they solve, of course. That said, code that seems decorative but actually helps the total appropriateness of the code is blessed indeed!
Now if more folks would just do that as opposed to "Just Glue It." Jeesh!
Speaking of TDD, Sam points us at TestDriven.net who offers a Studio add making it easier to actually use Nunit. Thanks!
I now resume my irrregular programming...
Like many of you, I'm addicted to the Doughnut. But I had been having a Doughnut-Free 2005 until falling off the wagon this morning. The Winchells is just to close to work to avoid forever. Now I don't know if this is just a test market thing or not, but it seems like drive-through around here has an automated greeting that can really throw you for a loop. You know, it starts with a friendly, "you can see me smiling with my words" kind of thing that leads you to expect that level of energy and competence is going to continue. Of course, it seldom does. And that can make for some amusing moments. They can also lead to a moment of self-awareness.
Me (after hearing such a greeting): Hi, I'd like three chocolate Doughnuts, please.
Time passes. I start thinking about why I don't like what The RebelGeek thinks would make XML 2.0 better -- more on that later and about the query Janell was showing me before I left for work.
Some Dude (who obviously wasn't the woman who greeted me, and who sounded like he'd rather be eating a gun than being at work): Uhh... sorry... whatja want?
Me (without thinking): select three doughnuts into sack where donut contains chocolate.
Some Dude: Dead slience for a moment, a loud chuckle followed by "$2.54 at the window please."
Now I don't know if a.) he thought I was a sociopath; b.) knew something about SQL; c.) something else caught is humors or d.) any combination of the previous but his reaction gave me pause.
Damn, its bad enough that I think in SQL, but talking to others in query form? That's just not right.