savas parastatidis

EPRs and the architectural elements they address

But which are our architectural elements you may ask? Services or resources? I posted my thoughts over at the W3C mailing list. For those who have been following what Jim and I have been saying about OGSI, WSRF (and to a lesser extent about WS-Transfer), this post is a short summary. Expect more when we finish our promised MEST paper (the long version).

Steve seems to think that I will be thrown out of W3C because of this :-).

Tim discusses the problems with the vendors’ lack of a shared understanding of the WS architecture (“When architectures collide”) and he links to my post as an example.

It seems to me that because of the lack of a shared vision of the WS architecture, the WS-* stack is becoming a set of technologies that will attempt to please everyone and enable everyone’s architectural visions. I have no doubt that this will be possible (resources, objects, services, etc.). It’s possible to build distributed-object-based applications using XML and SOAP as it is possible to build service-oriented applications using object-oriented toolsets (e.g. CORBA/DCOM/etc).

I was hoping that the WS-* stack would be a good set of focused tools for building interoperable service-oriented systems. Let’s see where the WS-Highway ends.

4 responses to “EPRs and the architectural elements they address”

  1. Mark Baker
    I agree with your gist here about the problems of trying to be everything to everybody, but I wanted to say, re the title, that services and resources are not architectural elements; they’re neither data, connectors, nor components, but instead abstractions presented through the interaction of those elements.
  2. Savas Parastatidis
    Hmmm… aren’t services a form of components? What about “building blocks”. Would have that been better?
  3. Mark Baker
    Hey! It’s possible that they could be made components, but I’d expect there’d be a container for them which would be the component, like a Web or App server. It doesn’t matter much to me what you call them (wouldn’t “services” suffice? 8-), I was just concerned about not calling them something they weren’t (at least in the context of the nomenclature of software architecture).
  4. Savas Parastatidis
    Agreed!