Web Services Architecture WG Issues Document

Original email

3.2.1 Top-level Goals

The Working Group has determined that at the highest level, its goals can be divided into 6 categories. Each of these is associated with the CSFs and requirements listed in [47]section 3.2.2

While it might be implied that these goals will be further expounded upon in 3.2.2, it might be useful to state this.

Original email

AC008 is consistent and coherent. This applies to both the reference architecture itself and the document that contains its definition.

Original email

D-AC001.1.1: Ensure that no individual implementor is favored over others.

While I continue to appreciate the sentiment, it sounds as if it will create dead locks. What happens if you have to make an arbitrary technical decision and *someone* benefits from it, can you not make the decision? A decision will always benefit someone more than someone else, however, you don't want this to be part of the reason for the decision. I think, instead, you want something like, "decisions will be not be made on the basis of favoring any particular implementor over others."

Original email

AG004 Security

Web Services Architecture must provide a secure environment for online processes. Critical success factors and requirements for this goal:

AC006 addresses the security of Web services across distributed domains and platforms.AC020 enables privacy protection for the consumer of a Web service across multiple domains and services. AG005 Scalability and ExtensibilityThe web services architecture must promote implementations that are scalable and extensible.

What do these terms mean: encourage/promote (perhaps use one?), enable, provide, and support?

• Encourage X: while out of scope of any technical specification, recommend X?

• Enable X: X can be implemented by using the facilities of the archtiecture (does this mean X can be implemented using the facilities of the architecture and nothing more?)

• Provie X: a concrete deliverable?

• Support X: Unlinke enable, X can be implemented by using the facilities of the architecture amongst other piences?

(A term I sometimes also use is, "not preclude".)

This is relevant to your later non-repudiation requirement. "Non-repudation" is typically determined by a combination of algorithm cryptography) properties and policy/legal definitions. Do you plan to require particular algorithms necessary for non-repudation? Or define what it means in your context?

AR016.1 Identify what constitutes interoperability

• D-AR016.1.1 in architectural realm.

• D-AR016.1.2 in technological realm.

What's the difference between the architectural and technical realm?

AC020

• AC020.2 Advertised Web Service privacy policies MUST be expressed in P3P.

AC020.2 Advertised Web Service privacy policies MUST be expressed in P3P.

Normative reference?

point 4 reads - 4. The travel agent service finds a list of airlines.

I think that should read:

4. The travel agent service finds a list of hotels.

Original Comments list email

The architecture draft[1] discusses MEPs as an architectural element. They currently appear in the document both as a SOAP feature and a WSDL description attribute. They are likely to show up in one form or another in other places, e.g. in choreography.

An interesting question is to know what relationships MEPs have in each of those "layers", if any. I would therefore like to add an issue in the document about how MEPs translate from one "layer" to another.

Some background discussions on this:

Discussion in the WSCG list

A (short) document comparing SOAP's and WSDL's approaches

architecture draft [1]

Comments listReference

section 1.3 says "A small and non-exclusive set of protocols for interchanging information between agents", which I believe is incorrect, because each WSDL document defines a new protocol. So perhaps more accurately we should say that the Web services architecture (currently) consists of a protocol framework which provides a means for each application to define its own protocol.

I agree with Chris' note that SOAP belongs in the protocol section, since it's principle value is as a protocol, despite it also having some of the properties of a format.

for the reason suggested in the first point above, I would also put WSDL in the protocols section.

The WS Architecture Requirements [1] document refers to "TAG Architecture Categorization" [2] as a normative reference. This is not a good idea since this web page clearly states:

"This is not a formal document in any sense, nor a working draft of the W3C. It is a working space for the TAG. Like all categorizations it is to a certain extent arbitrary. The tree structure below does not in any way dictate an order of writing the documents. This is not a formal document. It is more like a group note-book. It changes continually."

At best this reference should be an Informative Reference.

If you are looking for a normative reference I would recommend you consider using the " Architectural Principles of the World Wide Web" Working Draft [3] which is much more recent than [2].

[1]http://www.w3.org/TR/wsa-reqs

[2]http://www.w3.org/2001/tag/doc/toc

[3]http://www.w3.org/TR/2002/WD-webarch-20020830/

The definition in the glossary[1] is the same as the one in the requirements document[2].

However, the architecture document uses a slightly different one[3].

Editors, any idea where it comes from? I think the natural thing would be to use [2].

[1]http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/glossary/wsa-glossary.html?rev=1.12&content-type=text/html#webservice

[2]http://www.w3.org/TR/2002/WD-wsa-reqs-20021011#IDAGWEBD

[3]http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html#IDA1ZKFF

See Comments list e-mail

In preparation for the publication of the first draft of the WSA, I hereby raise this issue regarding Web architecture.

The architecture described in the soon-to-be-published version of the Web Services Architecture document[1], rejects the uniform interface constraint[2] of the Web, since it assumes the use of WSDL, a technology whose objective is to describe interfaces that are specific to individual components rather than generic to them all.

My preferred resolution to this issue would be the adoption of the uniform interface constraint into the work produced by existing and yet-to-be-created working groups in the Web Services Activity.

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html

[2]http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_5

See Comments list e-mail

See Comments list e-mail

When reading DavidB's comments about the discovery stuff being written
from a technology POV rather than exposing a problem, I remembered that
I had identified a similar problem with the use cases, while trying to
outline a REST friendly solution to the travel agent use case.  I didn't
finish, but got far enough to see that it was prescribing a means of
solving the problem.

http://internet.conveyor.com/RESTwiki/moin.cgi/WebServicesTravelAgentExample

There's three comments in there about solution-prescribing, two obvious
ones where it says "service requests a description of how to communicate
with the service found" (i.e. grab the WSDL), and one less obvious one
where a "confirmation number" is prescribed rather than a "confirmation
identifier".

See Comments list e-mail

I'd like to raise an issue that the architecture document currently
uses terminology such as "transport protocol", to refer to protocols
which, in the OSI or IETF network stack models, would be called
"application protocols", and moreover that these other stack models
already have a "transport protocol".

I request that Web services network stack model be described (and
layers and terms defined) and that this description be related to the
IETF and/or OSI network stack models.
			

See Comments list e-mail

I'd like to point out that the architecture document misuses the term
"transport protocol" in places, at least with respect to what it's
generally understood to mean outside of the Web services community.  In
particular, it refers to HTTP and other application protocols as
transport protocols in sections 3.1 and 4.1.1.  In addition, the naming
of the layer in the "wire stack" as "transport" seems quite inappropriate
if it is to engulf both transport and application protocols.

I see that some attempt has been made elsewhere to remedy this, which is
a good thing.
			

The definition of synchronous should be improved.

http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/glossary/wsa-glossary.html#synchronous