Re: MEPs vs. IOPs document updated.

David Booth wrote:

>
> I updated the MEPs vs. IOPs document per last week's discussion about 
> the wording of the assumptions that are listed:
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm 
>
>
> However, at this point I'm wondering if others find the "Assumptions" 
> section worth the effort to include.  I had initially included it to 
> help add clarity to our discussions about MEPs versus IOPs -- to 
> ensure that we're all talking the same language, since I noticed that 
> different people were making different assumptions.  However, it isn't 
> clear to me that it's worth spending time doing careful wordsmithing 
> of these assumptions.  Perhaps we would be better served if we simply 
> removed them, and discussed the MEPs versus IOPs, and let different 
> assumptions arise during the course of those discussions.
>
> What do others think? 


David,

I think that assumptions are important and at least couple of them 
should remain: We are listing that  WSDL is a contract for the clients 
of a server in the assumptions and this is a very important point to 
make. How MEPs and IOPs are intended to be used by a client goes into 
the heart of how this contract is realized. As a result, one of the 
major usages of WSDL today is for tools to generate clients 
automatically based on the contract expressed in WSDL. Hence, the 
existing (and implicit) MEP in WSDL 1.1 has been fundemantal in this 
regard. The question is what the abstract level targets.

For example, I regard that the "contract" that is expressed by IOP does 
not have any assumptions with regards to the client at all. It is a 
server centric contract, at the abstract level exposing only the 
messages that the service consumes and generates. This is why a client 
can not assume whether it is getting back a reply or not. I would claim 
it is not realistic to be able to write(or generate) a client of a 
service based on the information expressed by IOP and the abstract 
level. On the other hand, a MEP expresses the contract from the 
perspective of the client and the server. This is why one IOP may end up 
being expressed in two different MEPs. It is the MEPs that would allow 
clients of the server to be written and/or generated using only the 
abstract level in WSDL if they are exposed at that level.

For some of us, who are writing language binding tools especially, the 
distribution of responsibilities of how the contract works is very 
fundemantal. With one perspective, the abstract level as expressed with 
IOPs seems to favor only the server's perspective by disregarding the 
client(s). The  MEPs on the other hand allows the client's contract to 
be derived at the abstract level. Clients may be written or generated 
without relying on the binding information that could be supplied later 
if they know the MEP. Using IOPs, this does not seem to be possible.

This goes to the issue about our assumptions. One perspective assumes 
that the layered design of WSDL allows the client programmer to be able 
to write a program that communicates to a service based on the abstract 
definition of the service. Hence, the transport level definitions are 
derived based on the bindings may be supplied separately with the aid of 
tools, etc. but does not hinder the client. A different perspective is 
based on the assumption is that the client is not the ultimate consumer 
of the abstract level in WSDL. The client programmer can not write a 
program that connects to the service based on the information provided 
in the WSDL without interpreting the binding in some manner. The 
programmer must rely on some infrastructure tool to provide the 
necessary abstraction which may be a combination of  abstract + binding 
information. One can not write a client program by just consuming the 
WSDL at the abstract level and a IOP.

What I am getting is that the distinction of IOP vs. MEP is based on the 
assumptions about how the contract can be utilized by the client. 
Therefore, we should not remove the assumptions, especially (1), (2), 
and (4) which  I regard to be the basis of this analysis.


--umit



>
>
>

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com

Received on Wednesday, 28 May 2003 03:04:43 UTC