[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. Alastair -----Original Message----- 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, -- From:
Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] Yet another context management
specification from IBM et al: http://www.marketwire.com/mw/release_html_b1?release_id=61977 JJ- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]