- From: Hugo Haas <hugo@w3.org>
- Date: Mon, 5 May 2003 13:59:19 +0200
- To: Francis McCabe <fgm@fla.fujitsu.com>
- Cc: www-ws-arch@w3.org
[ Summary: for this round of publication, please search for "***". ]
I have reviewed the draft of the Web Services Architecture posted by
Frank last Thursday:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.13&content-type=text/html
Please note that the numbering of the sections might be wrong in some
places since I originally wrote this email after reading an earlier
version:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html?rev=1.10&content-type=text/html
Below are some comments about the draft. Overall, I think that the
document looks good. There are two editorial comments that I would
like to see addressed before publication, if possible; they are marked
with three stars (***). They are not controversial (I think) and
should be implementable a matter of a couple of minutes.
The other comments can be discussed at the face-to-face or be raised
as issues against the document.
| Web Services Architecture
[..]
| 1.5.3 Requester and Provider
Editorial comment: the draft sometimes uses "requester", and sometimes
"requestor". The editors should choose one and stick to it.
Note that the glossary reflects this be using both which is IMO a bug.
| 1.6.2 Relationship to Web Architecture
[..]
This whole section is about REST, and never uses the word Web whereas
the title talks about the Web architecture.
We need to add some text about the relationship between REST and the
Web architecture.
| 1.7 Web Service Technologies
|
| Web service architecture involves many layered and interrelated
| technologies. There are many ways to visualize these technologies, just as
| there are many ways to build and use Web services. Figure 3 provides one
| illustration of some of these technology families.
|
| Figure 3: Stack Diagram. [Not sure which version of this diagram we'll end
| up using. I've been collecting candidate diagrams in
| http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/candidate_diagrams.htm]Technology
| Layers (Stack Diagram)
*** The latest diagram that people agreed to (IIRC) is:
http://lists.w3.org/Archives/Public/www-ws-arch/2003Apr/att-0254/WSA_STACK.png
[..]
| 1.7.4 Transport
|
| Transport technologies, such as HTTP, JMS, FTP, SMTP, IIOP, provide a
| means of transferring messages from one place to another.
This is labeled "Communications" in the latest diagram.
[..]
| 2.2.2 Authentication
|
| 2.2.2.1 Summary
|
| Authentication is the process of verifying that a potential partner in a
| conversation is capable os representing a principal or legal entity
Without going into the details of merging the content of the glossary
with this section, this definition doesn't sound right to me.
Actually, the glossary doesn't define authentication. Well, RFC2828
says:
(I) The process of verifying an identity claimed by or for a
system entity. (See: authenticate, authentication exchange,
authentication information, credential, data origin
authentication, peer entity authentication.)
The capability of (typo) representing somebody sounds odd to me and
seems to go beyond authentication.
| 2.2.15 Message Exchange Pattern (MEP)
[..]
| 2.2.15.3 Description
I think that Mark Jones's text about MEPs should be added here, or in
section 3 (see below).
[..]
| 2.2.16 Message Header
|
| 2.2.16.1 Summary
|
| A message header is the part of the message that is available to any
| potential intermediaries and contains information about the message, such
| as its structure and the identity of the service provider.
|
| 2.2.16.2 Relationships to other elements
|
| a message header is part of
|
| a message
|
| a message header may contain
|
| message routing information
|
| a message header may contain
|
| message security information
|
| a message header may contain
|
| message orchestration information
|
| a message header may contain
|
| message transaction context
|
| 2.2.16.3 Description
|
| The header part of a message can include information pertinent to extended
| Web services functionality, such as security, transaction context,
| orchestration information, or message routing information.
All of those could be seen as features. Shouldn't we replace them by a
more general statement saying that a message header may implement a
feature?
[..]
| 2.2.18 Message Identifier
[..]
| 2.2.18.3 Description
|
| A message may have an identifier. In the context of Web services we expect
| to use URIs to represent message identifiers.
I don't think that we should _expect_ to use URIs. Being on the Web,
identifiers _are_ URIs:
http://www.w3.org/TR/2003/WD-webarch-20030326/#identification
[..]
| 2.2.19 Message recipient
|
| 2.2.19.1 Summary
|
| A message recipient is the agent that is intended -- by the message's
| sender -- to consume the message.
I would say: "a message recipient is _an_ agent [..]". Indeed, I don't
think that this summary is compatible with the case where a message
is sent to several recipients.
| 2.2.19.2 Relationships to other elements
|
| a message recipient is
|
| a agent
|
| 2.2.19.3 Description
|
| The message recipient is the agent that the sender intends the message to
| be consumed by. The message recipient of an agent may be represented as
| the agent's identifier in a message envelope; however, in the case of
| anonymous or broadcast-style interactions, the recipient of a message may
| not be available to the sender.
We should probably mention intermediaries here, which are actually
missing from the architecture document as a concept.
[..]
| 2.2.21 Representation
[..]
| 2.2.22 Resource
[..]
The relationship between resource, representation of a resource and a
service isn't documented except in the SOA sections.
This is an area that we need to address.
[..]
| 2.2.23 Service
[..]
| a service has
| a service description
| a service has
| a service interface
A few questions arise from reading this:
- how is the interface described?
- can't a service more than one interface?
I believe that there is an ongoing discussion about that in the Web
Services Description Working Group.
[..]
| 2.2.24 Service Oriented Architecture
[..]
I don't think that this is an architecture core concept and should be
moved elsewhere. There are 2 other places where SOA's are talked
about.
| 2.2.25 Service description
|
| 2.2.25.1 Summary
|
| A service description is a set of documents that describe the interface to
| and semantics of a service.
|
| 2.2.25.2 Relationships to other elements
|
| a service description is
|
| a description of a service
|
| a service description contains
|
| a description of the service's interface
[..]
Same comment about service description and service interface
description. We may need to simply separate the description of the
purpose of the service (what?) from the description of the interaction
mechanics (how?).
| 2.2.25.3 Description
|
| A service description contains the details of the interface and
| implementation of the service. This includes its data types, operations,
| binding information, and network location.
I don't think that binding is ever defined in the document. We should
definitely define this concept, especially since binding appears in
two contexts: SOAP and WSDL.
[..]
| There are many potential uses of service descriptions, they may be used to
| facilitate the construction and deployment of services, they may be used
| by people to locate appropriate services and they may be used by service
| requestors to automatically discover appropriate providers in those case
| where requestors are able to may suitable choices. However, service
| descriptions are not necessarily, or even primarily, intended for their
| use in automatic discovery.
I'm wondering about the usefulness of the last sentence, and even
whether it is correct or not. We should not make assumptions on how
this description is intended to be used in order not to preclude
certain uses.
| 3.4 Web Service Discovery
[..]
This section talks about discovery without mentioning discovery
services.
My feeling about that is that:
- discovery service is a concept that can be dropped.
- the difference between discovery and discovery service needs to be
illustrated in this section.
| 3.5 Web service semantics
This section does not mention the Semantic Web and actually has some
untrue statement:
| A third major distinction between this architecture and the World Wide
| Webis that, for computer programs to be able to interact with other in a
| meaningful way, it is necessary to model the semanticsof the information
| exchanged.
The Semantic Web is part of the World Wide Web and allows to add
meaning to concepts:
[[
The Semantic Web is the representation of data on the World Wide
Web. [..]
"The Semantic Web is an extension of the current web in which
information is given well-defined meaning, better enabling computers
and people to work in cooperation." -- Tim Berners-Lee, James
Hendler, Ora Lassila, The Semantic Web, Scientific American, May
2001
]] -- http://www.w3.org/2001/sw/
We need to acknowledge this work, and not have people think that our
architecture will conflict, replace or otherwise compete with the
goals of the Semantic Web.
*** I would like to see an editors note added to this section saying
that the Semantic Web needs to be acknowledged.
[..]
| 3.13 Web service manageability
|
| Goal AG007 of the requirements identifies that manageability of Web
| services is an important goal of this architecture.
|
| Management in this case is defined as a set of capabilities for
| discovering the existence, availability, health, and usage, as well the
| control and configuration of resources, where resources are defined as Web
| services, agents of the Web services architecture, and roles undertaken in
| the architecture.
This section mentions discovery of the existence of resources, but is
really vague about this and doesn't explain the relationship with
discovery (the core concept).
[..]
I think we are missing (at least the following subsections) under
section 3:
- choreography
- MEPs (maybe Mark Jones's text will fit better here than in the core
concepts section).
- security.
- privacy.
| 4 Constraints
|
| 4.1 Service Oriented Architecture
|
| SOA has an optional constraint, of described interface. The service is
| described in a description language of some kind. The description includes
| features such as the syntactic constraints on the service interface, the
| identifier for the service, and semantic information about the service.
| Meeting this constraint induces the properties of higher re-usability of
| the component.
|
| The Direct SOA has the same advantages as REST, such as better visibility,
| as the firewall can simply examine the generic interface to determine the
| action being performed. Intermediaries, such as HTTP routers or caches,
| can simply look at the method. An example is that a cache can look at the
| GET and the identifier, and return a cached representation. This is much
| more difficult if the method is in arbitrary places in the POST.
| Re-usability can be higher as the service may be available on the Web as a
| URI may be transferable.
The re-usability argument isn't very clear here IMO. I think that this
deserves to be further developed.
| The Mediated SOA has the advantage of protocol independence. There are
| limitations to HTTP that can be ameliorated by the use of SOAP. In cases
| of Service-oriented applications, such as messaging systems, it is easier
| to build applications in an SOA style. There may be higher Network
| Performance as the representations could be for multiple services.
|
| [NOTE: DaveO:] Need to say more about which styles are more effective.
|
| The following paragraphs provide some discourse on the notions of direct
| and indirect manipulation. It is possible for a Web service to be non-REST
| or REST compliant. A Web services based SOA may not support GET, and even
| may embed the equivalent of a GET inside a POST request. However, it is
| fact that the Web carries messages that contain Representations. So how
| can a Web service both: 1) non-REST compliant and 2) exchange
| representations? These seem to be in contradiction.
|
| The reconciliation is that a Web services based SOA may not be "on the
| web". Being "on the web" is about supporting a generic interface to a URI,
| particularly the HTTP GET method for http: schemed URIs. This is
| completely consistent with the web as it currently exists. An HTML page
| that is returned as a result of a POST method is a representation of the
| status of a Resource. But that resource is not identified with a URI (you
| can't do a GET on it). The URI that the form is POSTed to does NOT
| identify the resource that the web page represents. There are 2 resources
| in play. The first, identified with a URI, is a gateway resource. The
| second, not identified with a URI and not on the web, is hidden from the
| web by the first URI. There is a decoupling of the resource identifier
| from the resource that the form data is sent to. Typically the resource
| identified by the URI is a gateway of some kind. And this is completely
| acceptable to REST. Nobody in the world has suggested that the Web is
| broken because FORM POST URIs are not directly accessible via browsers. We
| still consider the form result to be a web page. Thus we can consider the
| result of a SOAP POST to be a Web service message with a representation,
| yet not "on the web".
It seems to me that we are missing a conclusion for this section.
| Style Summary. The set of constraints is: Layered, Client-Server,
| Cacheable, Stateless Connection, Specific interface, Described interface.
| In the vernacular of the Feilding thesis -LC$SCSIDI.
|
| References: Developer.com, Michael StevensEnhance Re-use by embracing a
| Service Oriented Architecture, Tim LandgraveThe evolution of Web
| applications into service-oriented components with Web services, Steve
| BurbeckRational's Using Service Oriented Architecture and Component Based
| Development to Build Web Applications, Alan Brown et allVinci, A Service
| Oriented Architecture, Rakesh Agrawal, et al Web Service Oriented
| Architecture, Annrai O'Toole
[..]
| 4.3.4 WSDL
[..]
This section will need to be updated with the latest WSDL 1.2
terminology.
Regards,
Hugo
--
Hugo Haas - http://larve.net/people/hugo/
Received on Monday, 5 May 2003 09:59:07 UTC