Re: Words for the Triangles

[ Preamble: I am catching up on things, so some of the things
  commented on might have been addressed already. ]

Hi Heather.

* Heather Kreger <kreger@us.ibm.com> [2002-09-24 14:23-0400]
> Here are the words I have for the triangles... and a shot at where the
> triangle variations would go. Its in HTML (genned from Word) and
> will need to be munged into the arch document by editors.
> 
> It is also a derivation fo the white paper we already had on Web Services
> "Web Services Conceptual Architecture". I have permission to plaguerize and
> contribute this to the w3c.  I tried to scrub it for blatent 'IBM View'
> stuff, I may have missed some.
> 
> (See attached file: HKsContribution.triangle.htm)
> 
> More words to follow on wire/description/discovery agency. I am taking the
> starter set from the same white paper and trying to re-munge for the
> discussions we've already had and some progress we've made in the industry
> that are not represented in my old words.

This is a good start. Some comments below:

> Web Services Architecture
> 
>    This section, briefly reviews web services as application integration
>    technology, defines the term web service and describes the web
>    services model.
> 
> 
> 
>    What the web did for program-to-user interactions, web services is
>    poised to do for program-to-program interactions. Web services will
>    help companies to reduce the cost of doing e-business, it will make it
>    possible for them to deploy solutions more rapidly, and it will open
>    up new opportunities for them. The key to reaching this new horizon is
>    a common program-to-program communication model, built on existing and
>    emerging standards such as HTTP, XML, SOAP, WSDL, and UDDI.

I wouldn't list UDDI here: it hints that the "common
program-to-program communication model" is based on a centralized
registry.

>    Web services allow applications to be integrated more rapidly, easily,
>    and cheaply than before. Web services enable integration at a higher
>    level in the protocol stack, based on messages that are centered on
>    service semantics (rather than network protocol semantics) enabling
>    loose integration of business functions. These are characteristics
>    that are ideal for connecting business functions across the web - both
>    between enterprises and within enterprises. They provide a unifying
>    programming model so that application integration inside and outside
>    the enterprise can be done with a common approach, leveraging common
>    infrastructure. Integration and application of web services can be
>    done in an incremental manner, using existing languages and platforms,
>    adopting existing legacy applications. Moreover, web services are
>    intended to compliment J2EE, CORBA and other standards for integration
>    of more tightly-coupled distributed and non-distributed applications.
>    Web services is a technology for deploying and providing access to
>    business functions over the web, and J2EE, CORBA, and other
>    traditional programming standards are technologies for implementing
>    web services.

Something is coming back to my mind: I see Web services (you can guess
here my favorite spelling) spelled [Ww]eb [Ss]ervices. It would be
good to have a consistent use of those words in the architecture
document, and elsewhere too actually. Web refers to the World Wide Web
is therefore "Web"; I think the issue is with "[Ss]ervices".

I don't mean to start a huge debate here, just raise the issue.

[..]
> Definition of Web Services
> 
>    A web service is an interface that describes a collection of
>    operations that are network accessible through standardized XML
>    messaging.
> 
> 
>     The official W3c definition: A Web service is a software system
>    identified by a URI, whose public interfaces and bindings are defined
>    and described using XML. Its definition can be discovered by other
>    software systems. These systems may then interact with the Web service
>    in a manner prescribed by its definition, using XML based messages
>    conveyed by internet protocols.

I would just reference the one we agreed upon for now here.

[..]
> The Web Services Oriented Architecture Model
> 
>    The web service architecture based upon the interactions between three
>    roles: service provider, service discovery agency, and service
>    requestor.

You were saying that you had issues finding a good way to call the
discovery part. I have the feeling that it actually may not be easily
described in terms of role.

In terms of abstract entities here, there is the provider and the
consumer. The discovery is something which happens between the two of
them, directly or indirectly. I would therefore suggest simply talking
about "discovery mechanisms".

[..]
> Roles in a Web Service Architecture
[..]
>    ·         The Service Discovery Agency. This is a searchable set of
>    service descriptions where service providers publish their service
>    descriptions. The service discovery agency can be centralized or
>    distributed. A discovery agency can support both the pattern where it
>    has descriptions sent to it and where the agency actively inspects
>    public providers for descriptions.  Service requestors find services
>    and obtain binding information (in the service descriptions) for
>    services during development for static binding, or during execution
>    for dynamic binding. For statically bound service requestors, the
>    service discovery agent is in fact an optional role in the
>    architecture, as a service provider can send the description directly
>    to service requestors. Likewise, service requestors can obtain a
>    service description from other sources besides a service registry,
>    such as a local file, FTP site, URL, or [INS: WSIL document :INS]
>    [DEL: ADS/DISCO :DEL] .

I would try to reword this, following my idea, as:

  Discovery mechanisms: this is a set of mechanism for the service
  requestor to become aware of the service provider and of how to
  invoke the service. Service requestors find services and obtain
  binding information (in the service descriptions) for services
  during development for static binding, or during execution for
  dynamic binding.

> Operations in a Web Service Architecture
[..]
>    The description of your service is used to publish it in a registry,
>    directory, or repository of service descriptions. After publication,
>    the registry also has a copy of your service description. At some
>    later time, a service requestor needs to use a service just like
>    yours. The service requestor, or client, finds your service in the
>    registry and retrieves the WSDL from the registry.

This is a centralized view of the discovery step. I think that this
could be changed by something like the "requestor somehow has access
to the service description".

Regards,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Wednesday, 25 September 2002 14:19:25 UTC