RE: Proposed text on reliability in the web services architecture

Bob:

As you move the context of the discussion from an action request to
interactions with a (distributed) object, you are introducing a whole
new class of problems that people have wrestling with for years. As I
said in my previous email, there is no good model for a "business
object" today, let alone for a "globally" distributed object model. When
you get some HTML from my server, I could not care less to what you do
with it. If I need to be notified of what you did with it, then you need
something more (WEBDAV). WebDAV works for documents but what about
business entities?

If a web service operation represent an interaction with this business
entity, the best you can do is downgrade it to be an action. If the
result of the action shipped to you as the response has now a lifecycle
that is not independent of the business object, let alone all these
serializations shipped to different clients in different sessions need
to be coordinated (not to mention kept in synch!), well that starts to
be a very complex problem.

The way I view the difference between XML serialization and
representation is the former looks like an HTML page served to a browser
while the other look like an EJB. At the metamodel level, and as Mike
pointed in its last email, a business entity has only one representation
but multiple possible serializations (based on what the client needs).

The problem is that without a discussion at the metamodel level, all
these notions look relatively the same (there is a lot of things that
you can do with a request/response protocol).

Jean-Jacques 
 
 

>>-----Original Message-----
>>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
On
>>Behalf Of bhaugen
>>Sent: Thursday, January 09, 2003 11:26 AM
>>To: www-ws-arch@w3.org
>>Subject: RE: Proposed text on reliability in the web services
architecture
>>
>>
>>Mike Champion continued:
>>> My guess would be that
>>> it is considerably easier to write adapters and mediators that don't
>>change
>>> fundamental architectural principles.  Maybe I'm missing something
>>myself,
>>> but it's *hard* to design systems that use the
resource/representation
>>> trasfer model, use safe retrieval and idempotent update, etc. if
>>you're used
>>> to ordinary OO design.
>>
>>In my ordinary OO design, I have orders, products, etc.
>>Why aren't those perfectly good Web resources with representations
>>responding to GET?
>>
>>(Yeah, I know, POST is another ball of mud...but refinement of
>>POST while adhering to REST would be a good Web service project...)
>>
>>> I can much more easily imagine writing an adapter
>>> that simply serializes objects as XML, interfaces with an app server
>>to
>>> maintain state, etc. than I can imagine writing an adapter that
>>presents a
>>> view of the objects as resources with representations that get
>>transferred
>>> around.
>>
>>What is the essential difference between an XML serialization
>>and a representation?
>>
>>> If there was an easy mapping from one to the other, I would have
>>> thought that the debates over the last year would be much easier :-)
>>
>>I think to resolve the debates over the last year requires
>>social and political services, not Web services.  If I could get
>>my wife to understand and be interested in the situation,
>>she could whip y'all into shape.
>>
>>
>>
>>

Received on Thursday, 9 January 2003 11:49:46 UTC