OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ws-caf] WS-Resource Framework

Hi Savas,


I think the distinction between “service-oriented” and “object-oriented” is bogus.


Consider two ways of accessing an operation --


“Service oriented”: address + identity + parameters

“Object oriented”: address + parameters


Or to put it another way: do I “see” an identity (context) outside the “address”, or is the identity concealed in the address?


This is an elusive boundary, impossible and futile to maintain in practice.


A URL of the form <protocol>://<domain>/<container/processor/sub-protocol-type>/<class-type>/<operation-type>/<identity> can identify an operation (piece of executable code), which can read in-bound parameters in the form of data in the message body of the protocol.


A URL of the form <protocol>://<domain>/ container/processor/sub-protocol /<class-type>/<operation-type> can identify an operation, which can read in-bound message data, the first part of which is an instance of the type <identity>, followed by the other parameters.


Who cares which way this is done? Only the client and the operation, who have “agreed” to use this form of parametization (context, identity) in the first place.


The client obviously needs to know the identity (context) to usefully communicate with the operation. If the client and the operation choose to pass the identity “by value”, in full, or “by reference” (key to a map or file), again, who cares? This is a matter of convenience, privacy etc. It makes no significant difference to how I build distributed systems. Ultimately, client function calls remote function, passing parameters. I can’t see any reason to boost one approach, or deprecate another.


Real work revolves around identified (related, collections of) resources. We need to parameterize operation instances. How parameters are passed is uninteresting. Identity (context) may be simple, direct and static, or multi-part, indirect and dynamic. These are application properties (matters of interpretation for the two interlocutors).


The implicit parameterization of objects has proved to be an extremely convenient way of programming. 90% of the service operations invoked in SOA deployments will be object methods. I do not believe that SOA is in contradiction with distributed objects, and I do not believe that SOA is a new world.


[Historical note: If by “object-oriented” people mean CORBA, and if they found that their CORBA implementor’s examples (suggesting a vast cloudburst of small, exported remote objects) did not in fact perform well with the CORBA product, then they should attack, not the concept of distributed objects, but one of the following four genuine and reasonable targets:


a. Their CORBA implementation

b. Their CORBA documentation and usage advice

c. The efficiency of the CORBA spec at a given stage in processor/memory/network evolution

d. Their own design]


To allow flexibility in addressing schemes, which may be constrained by container/processor/protocol features, useful addresses should have an “additional addressing information” slot, like the BTP addresses (and all those that have followed in the attempt to identify distinct resources for WS-related specs). Then you can do what you want, and call it what you want.




-----Original Message-----
From: Savas Parastatidis [mailto:Savas.Parastatidis@newcastle.ac.uk]
22 January 2004 06:36
To: ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] WS-Resource Framework


The specs and presentations can be found at:




BTW… they are trying hard to persuade people here at GlobusWORLD that the use of WS-Addressing to identify a “stateful resource” (a resource whose state can be represented as an XML document) is not the same as the use of context in the case of WS-AtomicTransaction. Personally, I can’t see the difference. They are both ways to do message correlation and achieve stateful interactions. The difference I see is that WS-Resource is a way to reason about distributed objects.


Now, whether people are going to start building loosely-coupled, large-scale applications around the concept of a stateful resource with a coupled identity (WS-Address + local identifier) and a coupled interface (the interface of the Web Service identified by the first part of the WS-Address) that will have to be decided. Personally, I think it still looks like distributed objects but the IBM folks over here assure me that they are not doing objects and are truly service-oriented. People here may disagree with me. I guess only time will tell whether this approach has any benefits.


In their presentations, they are making the following distinctions (I am not going to comment for now… I’ll leave this up to you):

- “A truly stateless service” (the set of operations that identify a Web service)

- “A conversational service”

- “A stateless service that acts upon stateful resources”


Best regards,

Savas Parastatidis
http://savas.parastatidis.name (now blogging)

From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com]
Sent: Thursday, January 22, 2004 6:07 AM
To: ws-caf@lists.oasis-open.org
Subject: [ws-caf] WS-Resource Framework


Yet another context management specification from IBM et al: http://www.marketwire.com/mw/release_html_b1?release_id=61977



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]