W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2002

Re: issue-intra-port-relationship

From: Prasad Yendluri <pyendluri@webmethods.com>
Date: Mon, 01 Jul 2002 14:39:02 -0700
Message-ID: <3D20CBF5.4A2C3DAD@webmethods.com>
To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
CC: Jonathan Marsh <jmarsh@microsoft.com>, www-ws-desc@w3.org
Sanjiva (et al),

Staying silent and not saying anything in the spec was what I was  proposing
(via the issue) also, unless of course people can recall why that restriction
was put in place. If we leave the restriction in place I request that we at
least state why that restriction needs to be in place.

Regards, Prasad

Sanjiva Weerawarana wrote:

> I'm actually ok with removing the current restriction and saying
> nothing about intra-port relationships. We actually talked about
> that possibility too at the F2F, but the minutes don't have much
> for this part. (It was late in the day and Jeff was getting tired ;-).)
>
> Bye,
>
> Sanjiva.
>

-------- Original Message --------
    Subject: Re: issue-intra-port-relationship (was ..Freshly updated draft of part1 (was:
             Re: Overloading [was RE: Minutes, 27 June 2002 Web Service Description Telcon]))
Resent-Date: Fri, 28 Jun 2002 14:34:51 -0400 (EDT)
Resent-From: www-ws-desc@w3.org
       Date: Fri, 28 Jun 2002 11:38:22 -0700
       From: Prasad Yendluri <pyendluri@webmethods.com>
         To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
         CC: Jonathan Marsh <jmarsh@microsoft.com>, www-ws-desc@w3.org
 References: <330564469BFEC046B84E591EB3D4D59C06A08422@red-msg-08.redmond.corp.microsoft.com>
             <036a01c21e4e$bead3560$c267b809@lankabook2>
             <038101c21e52$45154a90$c267b809@lankabook2>

Hi Sanjiva (et al),

Sanjiva Weerawarana wrote:

> I have also closed the following issue:
>
>     <issue id="issue-intra-port-relationship" status="closed">
>       <head>Should intra-port relationships be allowed?</head>
>       <source>Prasad Yendluri</source>
>       <p>The above restrictions seems to be unnecessary. What is the
>       justification?</p>
>       <resolution><p>Decided to retain this restriction as no one could
>       figure out what one would want with having this feature. See
>       Wed PM minutes for June '02 F2F.</p></resolution>
>     </issue>

Sorry I could not be at the F2F but, here is my two cents on this. Putting a
restriction without a justification seems unreasonable to me. We already have
several areas of confusing text in the spec that simply put restrictions w/o
offering any explanation (e.g. only one part in message when 'type' AII is
used; 'type' AII must be used in messages at abstract if SOAP binding 'use' is
'encoded' etc.).

Why put restriction and tie the hands when we can't think of a reason for
putting restriction? I offer couple of examples:

   * Say I have a service that offers query and search operations that are
     hosted on their own ports in the service. Query might need to invoke the
     search to accomplish its purpose sometime (or vice versa). Granted they
     can be put in separate services but if the provider feels they are
     closely related and really belong together why force one to do so?
   * Say we have a service that offers both higher level abstraction and
     lower-level fine-granular services (e.g. MAPI and IMAP) on separate ports
     and the MAPI operations  may need to invoke operations in IMAP port to
     accomplish its purpose. So the MAP port would want to "communicate" with
     the IMAP port. Again they can be in separate services and things would
     work fine. But these are just examples and why should the spec put a
     restriction and why not make the designers make these decisions, unless
     we see some bad side effects in permitting this?

It seems putting restrictions arbitrarily without justifying them is
undesirable IMHO.

"Ports within a service have the following relationship:

   *        None of the ports communicate with each other..." ?

My two cents..

Regards, Prasad
Received on Monday, 1 July 2002 17:35:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:21 GMT