post from Rich Turner (subscribed!)
It doesn’t surprise me one bit that this backlash is happening.
It’s inevitable whenever there’s no definition to back up a buzzword. Since
SOA is an architectural style, it needs to be defined in the language of
something that nobody is doing … well, unless you count this
decent first stab by
Dave Orchard (which didn’t make it into
the WSA document, unfortunately).
If the term “SOA” is going to have any meaning going forward,
somebody’s going to have to define it in a rigorous manner, it’s just
that simple. Any volunteers?
P.S. and to top it all off, that’s the good news for SOA. 8-)
I cancelled my Friendster account today, in protest of
their decision to
a friend of mine,
This was apparently, as I understand it, just because she blogged about work
related matters, although without revealing anything which wasn’t already publicly
available. The mind boggles.
If you’re doing Web stuff, you could do no better than her. Drop her
a line (and me too, while you’re at it 8-).
I realized a little while ago that my blog roll was quite one dimensional
in the subject matter it aggregated (namely, distributed computing). So, I’ve decided to
augment it with some other feeds related to a broader love of mine, design (in general,
not just software). For reasons unknown, I seem to be in a headspace recently
where I’m noticing design in practically everything. In fact, Adam
on one of them a couple of weeks ago; designing a startup (more on that later, perhaps,
as it’s something I have a lot of experience with).
So far I’ve only found two feeds that turned my crank (though without much effort
on my part, admittedly); MoCoLoco
which presents creative examples of industrial design, and Tesugen
by Peter Lindberg, which seems to cover design in general, though with an emphasis on urban
design and software architecture.
If anybody knows of any others, I’d be grateful for recommendations.
Everything you wanted to know about protocol testing
) [Mark Baker’s Bookmarks
But putting the misery of these experiences aside, I’m surprised at how little I’ve had to worry about SOAP. As it became clear to me that Web Services were becoming a menace to much of the goodness wrought by XML, I worried that I would be forced to do a lot of gritting my teeth at work while I accommodated clients’ insistence on WS. This hasn’t turned out to be the case. In several cases where WS “end points” have been suggested, I’ve been surprised at how easily my suggestions of a REST-like alternative are embraced (the fact that I could usually whip up running code in hours helped a lot).
That’s what I’m seeing too, at least once you’re in the door (though for a
pretty small sample space of two clients). On the other hand, looking for cool
large scale distributed systems work has becoming extremely painful since Web
services came onto the scene. Most projects are asking for “SOAP/WSDL/UDDI experience”,
which leaves me either having to lie and say “Oh yes, I’ve got lots” (which I
won’t do, of course), or else I have to put a pleasant face on WS-Insanity and
brave the inevitable lack of interest, as I did in my
He believes that, for the foreseeable future, the bulk of innovation in Internet scale systems will occur via additional architectural constraints applied to the Web; for example the Semantic Web, or the Two Way Web. Unfortunately, these beliefs also indicate to him that Web services have some serious architectural flaws that make their suitability as a large scale integration solution questionable. As a result, he spends considerable amounts of time working within standards setting organizations to ensure that these specifications – including SOAP 1.2 – take maximal advantage of the Web.
Simply put, business resources should be “one step back” from HTTP IMHO. When you send non-idempotent messages to a resource (e.g. POST/PUT), you send them to its inward bound, asynch message queue. You do not directly interact with the business resource.
Interesting position on queues, but I think you’ll eventually run into problems doing
that … though clearly not major problems, otherwise you’d have discovered them already 8-).
Whenever I want to do the queue thing, I use two resources; the “business resource”, and
“the inbound message queue for that business resource” (though of course, as a separate
resource, it need not be used only for the business resource). I then subscribe the business
resource to the queue, such that messages POSTed to the queue also are forwarded to the business
resource. FWIW, I’ve been using mod_pubsub
recently to manage the queue resource (as a topic
maintained by its router) in some work I’m doing on the side.
The problems I see with the approach Sean describes are a result of it not acknowledging
that the queue is a separate resource than the business resource, as this can lead to
ambiguities. For example, what can be expected from a GET on the URI;
a representation of the state of the business resource, or a representation of the state
of the queue?
That structure I described is probably a useful Web idiom to write up… I’ll put
it on my todo list. 8-)
P.S. I assume you wanted to say “non-safe” there, since PUT is idempotent.
I am talking about an architecture which only has services and messages, so where are the resources?
Aha! If that ain’t the $10,000 question … So, here’s my smart-ass 2c response;
Show me a message(*) and I’ll show you a representation of the state of some resource.
(*) a ProcessMessage message, aka a document.
In a really awesome
(sorry for the delay, I was on vacation),
ponders, among other things, what it would mean to be
a RESTafarian. It seems the one thing holding him back from
being a card carrying member of the club though, is that the
whole idea of binding application semantics to a protocol seems
sorta silly to him. Well, I don’t believe it is, but fortunately,
what you believe about that subject matters not to your
eligibility for membership. This is because REST, as an architectural
style, says nothing about how any particular architecture is
implemented. “All” it does is constrain your architectural elements.
So, if your architecture has uniform connector semantics (even if
there’s only a single one called “processThis”), and if your
architecture has a single data element which identifies resources which
act as message endpoints, and it uses fully
et cetera …,
then your architecture is RESTful, like it or not.
Savas, your card’s in the mail. 8-)
P.S. it hurts to type so don’t expect speedy email or blog replies – a side effect of skewering your
hand with a broken wine glass stem.
According to Radovan anyhow 8-)
Everyone programs in something different, so let’s just do
protocol-based integration, where we will just agree on the format of
the messages we are going to exchange over the wire.
I think this is the thing some ‘REST fundamentalists’ are still missing…
No, I think we get that. Or at least we get that it’s a critical
part of the solution. This is why HTTP 1.1 is as well specified as it is
(not that it doesn’t have issues, of course). The problem is that the
format is only one part of the solution. The other part are the
semantics of the messages, something that HTTP also specifies,
but SOAP doesn’t … not that it should though, as it can always inherit
them from the underlying protocol.
Right from the spec,
we have this example of an EPR;
<wsa:EndpointReference xmlns:wsa="..." xmlns:fabrikam="...">
Somebody please tell me why on earth that isn’t a URI? You know,