Re: Issue 146 proposed resolution

+1, in fact, +asmanyasIcangetawaywith

I would be heavily in favour of removing actor from Part 1 and defining an
extension for whatever 'actorlike' features we decide we need. I would also
strongly suggest that we define said extension outside of our current path
to REC. Many of the current issues we have to resolve are to do with actor
and/or intermediaries. Pushing this out into an extension that is defined
post 1.2 seems like an ideal way of keeping ( getting us back? ) on
schedule.

I've already done a *lot* of thinking about actor and I'm fairly convinced
that it *can* be done as an extension. Hopefully I'll get chance to post
some of my thoughts/designs in the next week.

Gudge

----- Original Message -----
From: "Doug Davis" <dug@us.ibm.com>
To: <Noah_Mendelsohn@lotus.com>
Cc: "Mark Baker" <distobj@acm.org>; "Henrik Frystyk Nielsen"
<henrikn@microsoft.com>; <skw@hplb.hpl.hp.com>; <xml-dist-app@w3.org>
Sent: Thursday, November 15, 2001 12:41 PM
Subject: Re: Issue 146 proposed resolution


> There is another choice:
> d) Get rid of actor and make all processing based on the acceptance
>    of the contract specified by the QName of the block.  This removes
>    this pseudo targeting that seems to be causing so many problems.
>    Everything is a black box anyway - so the QName should be the
>    determining factor.  We can get the semantics of actor="next"
>    other ways...
> :-)
> -Dug
>
>
> Noah_Mendelsohn@lotus.com@w3.org on 11/15/2001 12:14:20 PM
>
> Sent by:  xml-dist-app-request@w3.org
>
>
> To:   Mark Baker <distobj@acm.org>
> cc:   henrikn@microsoft.com (Henrik Frystyk Nielsen), skw@hplb.hpl.hp.com,
>       xml-dist-app@w3.org
> Subject:  Re: Issue 146 proposed resolution
>
>
>
> Mark Baker writes:
>
> >> It's important that SOAP support a gateway model,
> >> and in doing so, not attempt to prevent
> >> "processing the message" from including
> >> delegation to other processors.
>
> Agreed.   The question in my mind is, exactly how do we model it. As I
> understand Henrik, he is saying:  "there can be two nodes (and I mean
> "node" in exactly the formal sense of chapter 2) in the path taken by a
> given message both of which act in the role of the anonymous actor,
> neither of which is considered an intermediary;  nonetheless, the first
> one of these relays (again in the formal sense of "relay" per chapter 2)
> the message to the second.
>
> I still find this very problematic.  The formulations for this use case I
> would prefer are your choice of:
>
> a) From the point of view of the SOAP spec, there is a single endpoint
> node, which happens to have distributed logic, about which the SOAP spec
> says nothing.  You are always free to split your implementation in ways
> that the spec doesn't talk about, as long as you can identify the points
> in your system where conformant processing is done.
>
> b) The first such node is the true endpoint, and from a chapter 2 point of
> view the message path ends there.  If you choose to generate what SOAP
> believes to be a separate but very similar looking message to the second
> node, that's your business.  The second node is the endpoint for that
> message.  The response, if any, to the second message can be used to
> construct the resposne to the first.  This can either be done privately to
> the implementations, or per the specification for some SOAP extension
> feature.
>
> c) (the one I like least, I think)  get rid of the distinction between
> intermediaries and endpoints.  Just say that there are nodes that play the
> role of the anonymous actor (and hence process the body) and those that
> don't.
>
> Going to some trouble to distinguish intermediaries from endpoints, and
> then aving endpoints that act like intermediaries seems very strange to
> me.
>
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------
>
>
>
>
>

Received on Thursday, 15 November 2001 23:45:13 UTC