|
October 2006
October 24, 2006
Discipline & Punish SOA
On the "Disciple and Punish" blog, I ran into an interesting entry: Revisiting the Battle of Abstractions". For starters, I really like the rising acceptance I see of messaging in SOA. Not only at the transport level, messaging as a top-level communication paradigm is (finally) getting traction.
[Originally posted here]
What interests me, though, is that REpresentational State Transfer keeps getting compared to SOA. It's like comparing apples and types of pies. Yes, there maybe an type of pie which is an apple pie, which cannot be made without apples, but I don't think that that warrants talking about apples at the same level as pies.
Things like DDD which I see jiving very well with SOA don't do so well with REST. In REST terms, an Order may be a resource. In which case, a Customer would be a different resource. How then would business rules like cancelling an order line, causing a decrease in overall order cost, causing a decrease in customer orders for the quarter, causing the customer to lose the "preferred" status, be handled? How would this change be propogated to the caller of the original resource without some notification mechanism? Seeing as REST is (by its most vocal proponents) an HTTP only deal, who is in charge of handling reliable messaging - application-level code?
I'm willing to accept that REST is a valid choice for certain types of applications, however I think that a lot of difficult questions need to be answered before REST can be used in mission-critical systems.
Posted by Udi Dahan at 05:45 PM Permalink
|
October 20, 2006
Messaging Saga
Well, me and Arnon seem to be going round and round on the issue of messaging. All this sparked up from his original post "Queues are databases", and the latest installment is here. The current item is "Saga":
"a series of messages that goes back and forth between two (or more) services in a long running session"
I don't like the term "Saga". I prefer a term that reflects a different perspective: Long-running workflow.
The main difference being that a workflow has a clear initiator and purpose. Furthermore, workflow has state.
In fact, I like this term so much that I think I'll give a presentation about it at TechEd Developers Europe in a couple of weeks:
Adding Value to Message-based SOAs with Workflow (ARC307)
In large-scale, loosely-coupled distributed systems, services communicate with each other using asynchronous messaging patterns. However, this event-based publish/subscribe communication is often incapable of expressing high-value, cross service, business processes. In this session, we will see exactly how a service is structured and examine the various layers that support the top-level SOA concepts as well as those needed for long-running workflows. Don't write off SOA just yet; now that the hype's dying down, we can finally get back to work.
Anyway, back to the workflow-saga thing. Once you realize that a service that runs on multiple servers is involved in a long-running workflow, you will probably manage the state of that workflow in a database. Furthermore, the appropriate distribution of work by the workflow will ultimately express itself in low-coupling between multiple messages that are sent at the same time.
For example, sending a message to N partners for a price quote - N messages, that is. The order in which you receive responses doesn't matter. You could easily add rules like: "you must have at least M responses to continue the workflow", and "the maximum time to wait for a response is Y minutes". None of this creates a need for only-once and in-order handling of messages within the workflow.
Let's see what Arnon has to say about that!
Posted by Udi Dahan at 06:20 PM Permalink
|
Databases are queues are services are elephants are...
Arnon gave a nice writeup of one of the sessions at our recent meeting. The whole SOA thing came up again, but this time in the context of databases; so called Service Oriented Data Architectures (SODA). One of the points made in favour of SODA rested upon a thesis Jim Gray wrote a while ago entitled "Queues are databases". Anyway, I won't belabor the point seeing as Arnon handled that one. [Originally posted here]
What I do want to call out is Sql Server Service Broker's hard-won feature of only-once and in-order delivery. From Arnon's post:
"You can add readers to empty queues faster, and lock all related messages that are read by one of the readers (so you won't have a situation where one reader reads the order and another reads the same order's order-line before the first even updated the order into the database)."
And here's the kicker. Modeling your messages in such a way is a rather poor design. Why on earth would you take an Aggregate Root like an Order, and split it up into multiple messages - orderlines and the order itself separate?
It cracks me up time and time again. Some new fangled product bends over backwards trying to support some really hard feature, which is then touted as a key strength, which, in turn, makes more developers work that way. If you design your messages properly, you won't have any problem adding "readers" even without using Service Broker.
Posted by Udi Dahan at 11:06 AM Permalink
|
October 17, 2006
[Podcast] Parallel Processing and SOA
Get it here.
In this podcast we address non-functional requirements in SOA, such as throughput and latency. We'll discusses a whitepaper on the topic, as well as the use of pipeline architecture within a service to comply with SLA's that define these non-functional requirements. (MP3)
Resources
1. Whitepaper on Using Intelligent Parallel Processing in SOA
2. Ask Udi a question on SOA
3. Visit Udi's blog
4. Subscribe to the Ask Udi podcast
Enjoy.
Posted by Udi Dahan at 06:37 PM Permalink
|
Service-Oriented Elephants
I've been getting some emails and calls asking me what I think about Rocky's recent post Semantic coupling: the elephant in the SOA room. There have already been some comments on Rocky's site, not to mention Philip Nelson's post. What I want to address here is at two levels. The first is the feeling of frustration about what's going on in the SOA space. I sense that Rocky, and a lot of other people too, aren't particularly happy with this new craze, and I must say that I too share these feelings. Too many SOA evangelists who have been involved with too few large-scale projects in their careers are blowing smoke up the entire industry's arse.
From the first day I heard about SOA (about a year and a half, 2 years ago), I realized that Web Services wasn't the big deal. Or rather, from an EAI perspective, web services bring standardization, but they aren't going to solve the hard problems found in large-scale systems development.
Anyway, the second level I wanted to address will be on a more logical, point-by-point basis.
"It turns out, not surprisingly, that achieving real benefits in terms of reuse is much harder than the SOA evangelists would have anyone believe."
I've already mentioned before that reuse is not the point of SOA. It hasn't worked with objects or components, I really doubt we'll see anything different with services.
"I think this is because SOA focuses on only one part of the problem: syntactic coupling. SOA, or at least service-oriented design and programming, is very much centered around rules for addressing and binding to services, and around clear definition of syntactic contracts for the API and message data sent to and from services."
I'd disagree that this is what SOA focuses on. I'd say that Web Services focuses on that. And SOA does not equal Web Services.
"Semantic coupling is the harder part of the problem, and SOA does little or nothing to address this challenging issue."
I agree that semantic coupling is harder, but I would say that my view of SOA is all about addressing this issue.
"And this leaves us in a serious quandary. There’s a high cost to calling a service. There’s a lot of overhead to creating a message, serializing it into text (XML), routing it through some communications stack onto the wire, getting the electrons across the wire through some protocol (probably TCP) and all the attendant hardware involved, picking it up off the wire on the server, routing it through another communications stack, deserializing the text (XML) back into a meaningful message and finally interpreting the message. Only then can the service actually act on the message to do real work.
Worse, that’s only half the story, because most people are creating synchronous request/response services, and so that whole overhead cost must be paid again to get the result back to the caller!"
Which is why I gave a webcast for TechEd USA two years ago called You can't do SOA without messaging where I discussed the necessity of asynchronous messaging patterns to SOA.
"What’s even scarier, is that the vision of the future portrayed by the SOA evangelists is one where we build services (systems) that aggregate other services together to provide higher-level functionality. Like assembling simple blocks into more complex creations, that in turn can be assembled into more complex creations or used as-is."
Again, the whole building block paradigm of software development has been trying to take off for decades, but I don't see it happening any time soon. If you create, off the bat, large-scale business-level services there won't be much aggregating to do.
However, the question that Rocky raises is that he believes that large-scale services create higher levels of coupling.
"The broader the expected behavior, the tighter the coupling.
...
Contrast this with many other possible business services, such as shipping an order, or generating manufacturing documentation. In these (quite common) scenarios, the service performs, or is expected to perform, a relatively broad set of behaviors. The result is a whole group of effects and side-effects – all of which should be considered as black-box effects by any caller. But the more a service does, the less “black-box” it can be to its callers, and the tighter the coupling.
...
Do you even know what the ship-an-order service might do? Of course not, it is too big and vague. Will it trigger invoicing? Will it contact the customer? Will it print pick lists for inventory? Will it update the customer’s sales history?
I would hope it does all these things, but very few of us would be willing to blindly assume it does them. And so we are forced to treat ship-an-order as something other than a black box. At best it is gray, but probably downright clear. We’ll require that the service’s actual behaviors be documented. And then we’ll fill in the gaps for what it does not provide, or doesn’t provide in a way we like.
(Or, failing to get adequate documentation, we’ll experiment with the service, probing to find its effects and side-effects and limitations. And then we’ll fill in the gaps for the bits we don’t like. Sadly, this is the more common scenario…)
At this point we (the caller of the service) have become so coupled to the service, that any change to the service will almost certainly require a change to our code. And at this point we’ve lost the primary goal/benefit of SOA.
"
And that's saying a mouthfull. The only issue I have with all this is that the main objective of a service is NOT to serve. Pity we're stuck with the name service. The rise of the whole Event Driven Architecture thing seems to be based on this exact issue. Services don't exist in order to serve clients, they exist because they are an inherent part of the business, and as such respond to certain events occuring as well as raise their own events.
My recent article in the Microsoft Architecture Journal, Autonomous Services and Enterprise Entity Aggregation attempts to describe the differences in these two architectural styles.
Anyway, overall I'm in agreement with the jist of Rocky's post; don't take the bait offered by SOA evangelists (am I one too?) hook, line, and sinker without taking a long, hard look first.
Posted by Udi Dahan at 06:36 PM Permalink
|
October 06, 2006
AJAX & SOA to merge? puh-lease!
This came up on my radar, its from the WebSphere Power Magazine.
"Although technologists have been calling for the marriage of hot technologies such as SOAs and AJAX to help users better leverage Web services, the industry is only now beginning to see products that fully support this integration. At the AJAXWorld conference, JackBe and TIBCO Software are unveiling initiatives to more tightly link service-oriented architectures and Asynchronous JavaScript and XML."
First of all, as we already know, SOA is not a technology.
[Originally posted here]
Second, SOA is not dependent on Web Services, but can be implemented with them.
As for integration between AJAX and SOA, from the service's perspective, anyone can send it a message, and the service will then decide based on certain criteria (policy if you will) whether or not to handle the message or send a response. So, AJAX doesn't change anything in terms of SOA. As for the ability to send a message to a service, AJAX has certain limitations security-wise since it's run out of the browser, but these shouldn't be a problem.
So, it appears for lack of anything important to do, the vendors decided to invest in integrating stuff that can already work together just fine, maybe a point-and-click interface for developers?
Posted by Udi Dahan at 02:17 AM Permalink
|
October 03, 2006
SOA costs, savings, & value
After reading Harry Pierson's comments on an SOA workshop he attended presented by Thomas Erl, and the rest of the reuse bubble growing and popping, I wanted to add some comments from my experience in using SOA in the wild.
[originally published here]
First of all, the "reuse" is bull. In the cases where I found high reuse, I also found a function instead of a service. After some redesign, the function, and all the other "services" that "reused" it all collapsed into one, larger service. No more reuse. No need, really.
Second, about the costs of an SOA approach. They are higher. I repeat, it is more expensive to do SOA than continue what you are doing today. Developers are, by and large, not used to asynchronous programming. Doing SOA properly involves a mind-shift from the architects, through the team leaders, and all the way to the programmers. Call it a learning curve if you want. This costs. I don't know if its 30%, or more, or less. You will not be saving money by moving to SOA, at least, not tomorrow morning.
I assert that all this doesn't really matter.
The reason company's should move to SOA has to do with value. The looser coupling found in, and between, systems will decrease the time it takes to change and augment them. This translates to "business agility" (how I hate these hype-laden words). By decreasing overall complexity, the lifespan of systems will increase. In other words, you will be rewriting systems less, thus getting a higher return on investment on the systems that you've already built. Another "value-add" of the decreased complexity is that IT will be able to build larger and more powerful systems than before - integrating more processes and sharing more data across the enterprise. This, in turn, brings more of the right information to the right people at the right time, allowing them to make better decisions. You won't see all these things appearing in the cost-analysis of an SOA project I'm afraid.
Bottom line, do SOA for the value, or don't do it at all.
Posted by Udi Dahan at 05:53 PM Permalink
|
|
