- From: David Orchard <david.orchard@bea.com>
- Date: Mon, 11 Mar 2002 21:57:38 -0800
- To: <www-ws-arch@w3.org>
Another aspect of simplicity is re-use between specifications. I would like to ensure that data elements that are common across various modules of web services are re-used, rather than copied. A simplicity goal is that common data elements are not duplicated in messages or descriptions when multiple modules are mixed together. An example would be a messageID that might be required for correlation, reliability, and security headers. We don't want this ID to be duplicated in 3 different soap headers. Another aspect of simplicity is re-use of existing extensibility mechanisms. We do not want to recreate existing extensibility mechanisms, such as SOAP envelope or XML extensibility. Cheers, Dave > -----Original Message----- > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On > Behalf Of Champion, Mike > Sent: Thursday, March 07, 2002 6:18 PM > To: www-ws-arch@w3.org > Subject: D-AG0005 - Simplicity Requirement > > > This is my "get the ball rolling" message I agreed to post: > > The current wording of this requirement says simply "provides > simplicity and > ease-of-use that does not impose high barriers to > entry for users of web > services". As we discussed today, there are several dimensions to > "simplicity and ease of use" that need to be brought out in our > deliberations, and possibly in the requirements. > > First, is "simple for whom?" We identified three types of uses of our > architecture: > - Spec writers in WG's defining components we identify (e.g., > the WSD WG) > - Programmers implementing those specifications > - End-users of those implementations (e.g., customers using a > web services > IDE) > > Also, "simplicity" of what we produce means different things: > - The exposition of the architecture is easy to understand -- > clear prose, > helpful illustrations, etc. > - A small number of concepts and relationships suffices to > describe the > architecture > - The target audience has little difficulty using the architecture > > Furthermore, there are tradeoffs among these goal. For > example, a truly > minimal and elegant definition of the architecture would probably use > formalisms that made it difficult for much of the audience to > understand. > Likewise, "minimilistic" approaches in general are easy to > understand and > implement, but cumbersome to use because they lack > "convenience classes" to > do common things in a way that simplifies life for the end > user while making > more work for the implementer. > > Here's some strawman language that is a first attempt to > reconcile all this: > > "The W3C Web Services Reference Architecture is intended > primarily for the > use of other working groups specifying the components > identified in the > architecture, secondarily for developers implementing the > components, and > incidentally for end users of those components. The exposition of the > reference architecture MUST, to the greatest extent feasible, be > understandable by a "typical" experienced software > designer/developer: it > should use a minimum of specialized jargon, employ simple declarative > sentences wherever possible, and be organized and illustrated > in a way to > minimize the amount of effort required to understand it. The > reference > architecture SHOULD specify as few components and relationships as are > minimally necessary meet the other requirements. The > reference architecture > MAY, within the other contstraints, describe use cases and > examples intended > to clarify how an application programmer would use its > components to build > typical applications that utilize web services." > > Flame away ... > >
Received on Tuesday, 12 March 2002 12:49:12 UTC