RE: arch diagrams from the f2f

For point (2), I think it really depends on whether it is a human at design 
time doing a manual discovery OR a program at runtime doing a 
discovery.  In the former, probably the human can based on some vague 
metadata definition to find the service provider he wants, and then extract 
the detail interface before he start writing his code.  But in the later 
case, the "interface" is the program-level contract.  The program has to 
find ANY provider who complies to the interface, otherwise the code will be 
broken.  So in the later case, searching for a provider that support a 
particular "interface" happens first, then select a provider within that 
qualified range.

I'm actually thinking UDDI is trying to enable the latter case (what degree 
of success is another question).  Thats how it differentiate with xmethods 
who covers the former case.

Rgds, Ricky

At 10:59 AM 9/20/2002 -0400, Sedukhin, Igor wrote:

>1. probably falls in the area of SLA, BLA and other provisioning.
>"consumer" needs the "service", "service" is hosted by the "provider".
>Therefore I would not mix it into the baseline "consumer" -> "service"
>concept.
>
>2. I think that interface discovery is secondary. Once "consumer" found
>a "service" with a business criteria and found where it is hosted, as a
>second step, "consumer" would try to figure out how to talk to the
>"service". Hence interface is secondary. There could be a few special
>cases when "consumer" is looking for "services" given a particular
>interface. In those cases the discovery happens in the same way (could
>be P2P discovery as well). Then interfaces (a.k.a. contracts) are
>matched with the equivalence rules.
>
>-- Igor Sedukhin .. (igor.sedukhin@ca.com)
>-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
>
>
>-----Original Message-----
>From: Heather Kreger [mailto:kreger@us.ibm.com]
>Sent: Thursday, September 19, 2002 9:56 PM
>To: www-ws-arch@w3.org; jones@research.att.com
>Subject: RE: arch diagrams from the f2f
>
>
>
>
>
>
>
>Very interesting points,
>So, we have two concepts to bring in:
>
>1. Service Provider Description
>We have distinguished between service and service provider in the
>diagram. The service is the oval.
>
>When we were 'counting' on UDDI as the registry, we used to say that a
>'complete description' was created by adding the business
>characteristics, service provider characteristics, and categorization to
>the interface and implementation description. The UDDI entry carried
>this description.
>
>I agree, we need to factor that in business description, service
>provider description, and categorization description.
>
>Should we add a layer over policy for 'service provider description' ?
>I was thinking that policy will usually apply to a service instance,
>just like implementation and interface.
>
>2. location discovery and interface discovery
>I also think its VERY interesting to differentiatate between location
>discovery and interface discovery. Thats an important point thats often
>glossed over and forgotten.
>
>How do we represent this? two arrows to the discovery agency?  Does that
>mean there are also two publishes? interface and location? I think they
>are parallel concepts.
>
>Heather Kreger
>Web Services Lead Architect
>STSM, SWG Emerging Technology
>kreger@us.ibm.com
>919-543-3211 (t/l 441)  cell:919-496-9572
>
>
>jones@research.att.com on 09/19/2002 01:39:45 PM
>
>To:    distobj@acm.org, dorchard@bea.com, jones@research.att.com
>cc:    Heather Kreger/Raleigh/IBM@IBMUS, www-ws-arch@w3.org
>Subject:    RE: arch diagrams from the f2f
>
>
>
>There is yet another issue muddled together in the description space. We
>need to distinguish between describing the service provider and a
>service being offered.  As in real life, I might want to select a
>service not only on the basis of the service offered, but also on
>parameters associated with the provider (number of years in business,
>privacy policies, etc.).
>
>Maybe the top of the logical description hierarchy should look like:
>   service provider description
>     (properties of providers,
>      references to services they provide, ...)
>   service description
>     (properties of a service,
>      backpointers to service providers??,
>      references to service interface descriptions,
>      service addresses)
>   service interface description
>
>In some schemes, given a service address, you can recover the other
>information associated with the service.  To get the service address in
>the first place, however, you might have to search based on properties
>of the service.
>
>In other schemes, the search might return a reference to a resource that
>represents the entire service description (properties, interface
>descriptions, service addresses, etc.).
>
>In this modeling exercise, we should probably think hard about what
>things we want to explicitly think of as (URI-referenceable) resources
>by the way.
>
>Mark Jones
>AT&T
>
>  From www-ws-arch-request@w3.org Thu Sep 19 12:52 EDT 2002
>  Delivered-To: jones@research.att.com
>  X-Authentication-Warning: mail-red.research.att.com: postfixfilter set
>sender to www-ws-arch-request@w3.org using -f
>  Resent-Date: Thu, 19 Sep 2002 12:52:29 -0400 (EDT)
>  Resent-Message-Id: <200209191652.g8JGqTl14186@frink.w3.org>
>  From: "David Orchard" <dorchard@bea.com>
>  To: "'Mark Baker'" <distobj@acm.org>, <jones@research.att.com>
>  Cc: <kreger@us.ibm.com>, <www-ws-arch@w3.org>
>  Date: Thu, 19 Sep 2002 09:48:24 -0700
>  MIME-Version: 1.0
>  Content-Transfer-Encoding: 7bit
>  X-Priority: 3 (Normal)
>  X-MSMail-Priority: Normal
>  Importance: Normal
>  X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
>  Subject: RE: arch diagrams from the f2f
>  Resent-From: www-ws-arch@w3.org
>  X-Mailing-List: <www-ws-arch@w3.org> archive/latest/2531
>  X-Loop: www-ws-arch@w3.org
>  Resent-Sender: www-ws-arch-request@w3.org
>  List-Id: <www-ws-arch.w3.org>
>  List-Help: <http://www.w3.org/Mail/>
>  List-Unsubscribe:
><mailto:www-ws-arch-request@w3.org?subject=unsubscribe>
>  X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED
>version=2.20
>
>
>  I think there are 2 issues that are being muddled together.  We
>probably  need to separate them.
>
>  There are at least 2 things that can be found from a "registry": The
>actual  address of a resource, and the interface for interacting with
>it.  Mark  Baker is pointing out that there is no need to publish the
>input interface  for HTTP services, as HTTP defines the input interface.
>For services that  use SOAP, or other XML defined inputs, there may a
>need to discover the  interface.  For example, a conversational web
>service might require a soap  header with a conversation ID or a
>callback address.  This discovery could  be through a variety of means -
>somebody mails me a copy of the spec, I  discover the spec in UDDI
>registry, I de-ref a namespace URI, etc.
>
>  I think we need to distinguish between discovering the address of the
>service, and the shape or interface of messages to and from the service.
>
>  And BTW, I still don't think that HTTP is as generic as it appears.  To
>actually put information into the URL  and/or message, I as a human
>still  have to do some work.  Like fill in a form.  And the only way I
>know what  to  put in the form is to "discover" the shape of the form
>from the web site.  So in a form case, I get an address to the service,
>and the service  provides  the discovery mechanism and any new address
>for the actual service.  Imagine  url A accesses return the form, and
>the form says that it should be posted  to url B.  Thus the
>discover/interact model for addresses and shapes is  used  by the web.
>
>  Cheers,
>  Dave
>
>  > -----Original Message-----
>  > From: www-ws-arch-request@w3.org
>[mailto:www-ws-arch-request@w3.org]On
>  > Behalf Of Mark Baker
>  > Sent: Thursday, September 19, 2002 9:37 AM
>  > To: jones@research.att.com
>  > Cc: distobj@acm.org; kreger@us.ibm.com; www-ws-arch@w3.org
>  > Subject: Re: arch diagrams from the f2f
>  >
>  >
>  >
>  > On Thu, Sep 19, 2002 at 11:08:17AM -0400,
>  > jones@research.att.com wrote:
>  > > You somehow still have to come by the URI in the first
>  > place, whether
>  > > by work of mouth, google, etc.
>  >
>  > A previous GET ...
>  >
>  > >  Being spidered is a form of "publish".
>  >
>  > I'd say spidering was "interact" and "find".  "publish" would  > be
>listing  > your URI via POST at http://www.google.com/addurl.html  >  >
> > Using google is a form of "find".  >  > To search, sure.  But it's
>also "interact".  >  > I'm going to drop this now.  I'm trying hard to
>focus on the  > architecture document and SOAP+WSDL, but I can't help
>but comment on  > things I see being a concern later on.  >  > MB  > --
> > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
>  > Ottawa, Ontario, CANADA.               distobj@acm.org
>  > http://www.markbaker.ca        http://www.idokorro.com
>  >
>  >

Received on Friday, 20 September 2002 11:45:44 UTC