RE: proposal for faults

> Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] writes:
> "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com>
> >
> > Perhaps I have misunderstood your point here, but this is not the
> > current design of the patterns, so this proposal has the difficult
task
> > of proposing a simultaneous change there. The current abstraction of
the
> > pattern URI is quite consistent: it does not define specific message
> > types nor specific fault types. Requiring it to do the latter when
it
> > does not do the former seems completely unreasonable. Would the
> > request-response pattern URI definition define application-level
faults
> > to the request?
> 
> (I sent a direct response to Jeffrey by mistake .. this that + more
> thoughts.)
> 
> Oops, you're right .. but faults are of course different from other
> messages in that other messages in a pattern have a 1-1 relationship
> with an actual message. Hmm, I guess in general even that may not be
> the case.
> 
> I see we need more thought/work in this area. Can  we live with a 1-1
> relationship for message references to real messages? 

Yes

> Otherwise
> even that gets messy.

Agreed

> For faults, I guess I see that a single fault ref can be implemented
> by different app level fault types and there's no way the pattern
> def can take that into account. Given that, I'd be ok with allowing
> one to repeat <fault> elements with the same messageReference value
> to have the semantic that Roberto indicated. Roberto's syntax pref
> is ok too, 

OK

> but I'm a bit concerned with syntactic non-similarity with
> input/output.

Agreed

> Sanjiva.

Received on Thursday, 2 October 2003 11:17:06 UTC