Re: SOAP Binding Framework Concerns

Marwan,

I'm not sure that I agree. It should be possible to have the
application resolve a service endpoint at deploy or runtime
in which case the application developer need not be concerned
with the protocol, only that it satisfies/supports a particular
MEP. How that MEP is handled at the protocol level is (or should be) the
problem of the binding implementation, not the application.

A service may also be accessed via multiple protocols, and it should
be possible to shield the service implementation (application) from
the underlying protocol(s) thus allowing the same code to be
accessed via multiple channels.

Cheers,

Chris
Marwan Sabbouh wrote:

<snip/>
> 
> Your assertion:  if the binding support a specific
> flavour of request response ( where a specific flavour of request
> response is identified by a URI and is an instance of a message exchange
> pattern... , then we "can write my SOAP application in blissfull ignorance of which
> underlying protocol is being used rather than tying it to a particular underlying protocol
> and it's details"
> 
> Please explain that?
> 
>  it is unclear to me how the above assertion hold true or what  the real value is. It seems
> to me that the SOAP application programmer still needs ( and wants) to specify the protocol
> he needs to use.  It is true that he does not need ( want) to deal with the details of the
> protocol, but this is possible whether or not you specify those MEPs and is done by the SOAP
> vendor.


> 
> Thanks;
> Marwan
> 
> 
>>>Case 2: Someone would like to provide reliability and correlation at a higher layer.
>>>
>>Agree with what you wrote here. We provide the module framework (i.e.
>>the SOAP envelope and processing rules) rather than every conceivable
>>module. The binding framework is trying to do the same thing below SOAP.
>>
>>Regards,
>>Marc.
>>--
>>Marc Hadley <marc.hadley@sun.com>
>>XML Technology Centre, Sun Microsystems.
>>
> 
>

Received on Thursday, 25 October 2001 11:51:05 UTC