Re: SOAP Binding Framework Concerns

hi Chris;


Let us get the easy ones first.

You wrote:

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.

Comments:

You can do that. That is possible.  However, defining MEPs at the protocol binding layer has
nothing to do with it! ( that is the point of contention, right? not whether it should be possible
or not)  In other words, there is no relation between defining MEPs in the binding layer and the
above statement.  There is no need to tie the two together as Marc proposed.
Please explain how defining MEP at the protocol binding layer is beneficial to that end.  What are
the advantages? give specific examples, etc..

For example; a SOAP vendor may specify the same set of interfaces for application developpers
regardless of the underlying protocol.


You wrote:

 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.


I assume by application  you mean a SOAP application consumer ( a client)

A client, as described above,  does not worry about whether a MEP is satisfied by a particular
protocol.  This is always true whether we define MEPs at the binding layer or not. ( I am saying
we are creating this dependency!)  This is because the publisher of the service binds itself to
those protocols, ensuring their proper support.  So a SOAP vendor could provide an implementation
that
1) consume the WSDL file
2) properly initialize the communication stack
3)Initialize the interface
4)Invoke the generic method
5) Get the reply

without the application doing any protocol specific work.

Best Regards;
Marwan

Christopher Ferris wrote:

> 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 13:46:27 UTC