I am a fan of EDA - Event Driven Architecture. I posted about it a bit here.
Its nice and all, but it is not without its problems. It certainly has a role to play in any architecture. But the last time I built one, I ran into some problems as detailed in my series linked to above.
Does SBA (Space Based Architecture) simplify things even more? For one thing, it minimizes "legacy" XML which is certainly a good thing. And the location transparency is mind boggling. Makes things like Sonic's shared subscriptions look quaint.
Just when you were happy that web services are finally dead, there is another shift. And if you are still talking about web services, well . . . sorry.
11 comments:
Web Services dead? Don't think so. Commercial software vendors which represent the vast majority of what large business uses, are still investing heavily (if not more than ever) in Web Services and their governance.
I like EDA as well but Web Services do have a role to play in the mainstream corporate enterprise. I have found that there is a need for both as well.
Perhaps I should have been more specific ... WS-* is dead.
And if you don't think so then, well ... sorry.
I think we are on the same page now. The WS-* standards are to numerous and to complex for most practical implementations. They seem to really defeat the purpose for which Web Services are seeking to fill. There are a couple I think that will survive but the other 2 million of them are doomed.
Mike -
Reading your blog and Patrick Logan's, I get envious. Sounds like you're working on cool stuff.
Do you know if Liberty Mutual on this coast is doing the same kind of fun stuff?
- Bob Erb
Ah, "Space" as in "Tuple Space." Hope the concept stays nice and clean while it is being mangled through the Enterprise machine...
Re: the enterprise machine
We shall try, we shall try ;)
Bob,
Certainly are hiring at LM - Patrick and my team isn't at the moment. Liberty is a pretty big company so our views certainly aren't the consensus.
But Insurance in general is pretty IT intensive which is good for us geeks.
And I like where I work for lots of reasons. Mostly because I feel empowered and inspired and work with insanely smart people like Patrick!
If you want, send me your resume or an email (see profile) and we can discuss further.
Mike
You mean tuple spaces? I was working on that idea myself about two years back. I didn't take it very far, and haven't looked at it since. Right now, I think there's room for something like this, but I bet it can be mapped to HTTP a lot easier than you think.
Pete,
Thanks for the comment! You have had some great posts on your blog lately. And hey I'm a happy Burton Group customer.
I am as big a fan of REST vs. WS-* as any thinking person, but we need honest to goodness middleware for many of the things we build and I'm ok with that. I blogged about this topic a bunch months ago and was unable to convince myself that middleware is not necessary. I see heaps of value for REST at the periphery, but at the core of very large and complex transaction systems they aren't great. Reliable messaging is nice, events are nice, spaces may be nice. HTTP is nice too - just doesn't cut it for all things. Not saying you are saying that and am definitely willing to listen because I like simple solutions. Yes I am an enterprise guy, but I don't fit the typical mold you describe on your blog ("They're not listening").
Can you expound on what you mean by "but I bet it can be mapped to HTTP a lot easier than you think."?
Trust me, I like middleware too. Always have. It has a definite place in most enterprise infrastructures and addresses messaging needs not inherent in HTTP.
I'm not sure what it is you're building or what industrial strength processing you might need. But if you need basic...
Reliability: Only POST is not reliable (as the other verbs are idempotent), and that can be worked around internally. Or you can try adopting one of several reliable HTTP solutions in the works e.g. http://www.dehora.net/doc/httplr/draft-httplr-01.html
Asynchrony: HTTP is easily made asynchronous. Client posts message, server responds with 202- Accepted and a URL to poll for updates. Alternately, client can post a message along with the URL the server can post to when it's completed processing.
Finally, the topics and queues and spaces you're considering can also be exposed as resources with the obvious HTTP operation mappings. This exposes your event sinks to a broader number of participants (though you sacrifice end to end reliability) and, in these cases, eliminates the need to deploy proprietary drivers and APIs to these endpoints. http://www.activemq.org/site/rest.html
So, use the MOM of your choice as requirements dictate, and consider mapping it to HTTP for greater reach and simplicity. But if your requirement is _simple_ reliability and asychrony, you can probably go without a MOM altogether.
Pete,
Thanks again.
Yep I have been through all of that. See my labels named "mom" and "eda".
I did not know about Bill de hÓra's spec though so thanks. I was looking for something like that a while ago. Why aren't these things actually catching on (i.e., implementations)? Surely I'm not the only one that has heaps and heaps of services where REST or WS-* falls down into a coupled point-2-point overly-smart client mess? Guaranteed delivery simplifies things. Surely I'm not the only one that needs pub/sub etc.?
Or maybe I'm just a poser and I really am enterprisey. Not sure which.
Thanks for the post!
Post a Comment