|
|
||||||||||||
|
|
|
||||||||||||||||
|
|||||||||||||||||
Strategic architecture for Web services
Working drafts are out: W3C Web services working groups update
documents
{Apr 29 Rich Katz, JavaSkyline - Updated} According to the W3C Web services architectural working group (WSAWG) Web services is a new paradigm. Web servies has a large number of operational requirements - overall qualities of operations such as "performance," "security" and so on. The importance of these qualities calls for a re-framing of development methodology - and this re-framing starts with the requirement gathering and organizing phase. The new methodology must place equal emphasis on systems as opposed to applications. And it must address these operatoinal qualities in a meningful way - you can't just agree on them, list them, and forget them, but instead, you need to formulate realistic targets that contribute to meeting these requirements.
So goes some of the thinking of of the W3C Web services architecture working group.
Take a look at what they're thinking and you get a small glimpse into the future of Web services design.
Editors for the two groups have so far posted the following:
The report below summarizes the editors copies that were published a few days eariler. Among the few things that have changed, the Web services architecture working group (WSAWG) takes on the task of dealing with Use Cases and Usage Scenarios - so the problem of having two sets of usage scenarios may be going away.
Web services architectural requirements
(Apr 23rd)
Analysis methods and CSF
The document is especially interesting in that it establishes analysis methodologies. According to the document, the W3C will call for two analysis methods:
What's CSF? An overview of CSFanalysis was presented to the group in the April 8th meeting. CSF analysis is a suitable method for systems that have high levels of operational needs or "mission critical" needs. Operational needs including performance, reliability, security play important roles in a distributed environment such as Web services. Such areas are considered as critical success factors. During the analysis, problems are identified that require solutions.
CSF analysis starts with a mission statement and proceeds largely as hierarchial organization of goals. The CSF analysis then cross-references requirements with use cases and with the problems that are found see Daniel Austin's presentation: PPT, HTML.
CSF analysis thus somewhat resembles traditional goal analysis - similar to logic programming. You state one goal. And then you define that goal with other goals. For instance, let's look at a sample goal called "High performance." First state the goal - like this.
GOAL 1 "The XYZ must maintain a high level of performance throughout."
You've seen statements like this before. Where? In thousands of "boiler-plate"add-on pages that are attached to a software proposal and then are largely ignored. What's different with CSF is that next steps are defined that are designed to organize the work to meet the goal - like this.
GOAL 1 "The XYZ must maintain a high level of performance throughout."
1.1 Performance tracking by tier: Define a means of testing and evaluating performance criteria for each system
tier
1.2.Hire a performance specialist who can conduct testing, and identify bottle necks, and evaluate performance
problems.
CSF analysis is different from traditional analysis. First, as you can see even this short list of subgoals begins to enable delegation and problem tracking - which is the second phase of CSF analysis. Also, CSF analysis treats each operational requirement as a separate system to be analyzed.
Web service architecture: Main goals
Having established the methodology, the WSAWG document turns to the more concrete consideration of the top level
of actual requirements.
The document section on goals then constructs goal hierarchies for Web
services architecture under this top level. The April 23rd version included
some diagram sketches (shown right) where we get a first diagrammatic glimpse of how CSF analysis can be used to
delegating goal satisfaction to lower levels in the hierarchy. In the April 24th version, the diagrams no longer
appear but are replaced by a document link hierarchy.
In either case, effect is to break down big concepts into accomplishable tasks. For instance, examining the document,
one can see how a main goal like D-AG001 "Conformance and Interoperability" is broken down into tasks
that can be accomplished such as the "identify all interfaces and messages" task.
The rest of the document consists of analysis sections that will be used to cross-reference problems and use cases with the requirements.
The thing in itself
One of the parts of the WSAWG document I like the most is its very simple and unambgiuous definition of a Web service:
A web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols
If that's were this group managed to accomplish, I think it would be considered a success just for having arrived at a definition. However, the purpose of the WSAWG group is larger. As outlined in the document, the WSAWG is to construct a reference architecture for Web services. As Danial Austin points out, the work of the committee is largely to address the requirements of developers (and other W3 groups) as opposed to end users, so the use cases will be largely aimed at developers.
|
Web services description requirements (Apr 17th) This document contains a list of requirements and their status in the following areas
See the document for more detail. The document lists over 100 numbered requirements and describes which are accepted and which are rejected. The document obviously has gone through a lot of work yet seems still highly preliminary It will probably become more well formed after some rejected items have been removed. Exploration of requirements seems to have been somewhat a "depth first" style where rejected items require more verbage while the accepted ones are generally terse. Surely the right hand know what the left hand is
doing and don't call me Shirley dept. Hopefullly if there is a mapping to RDF this also implies a mapping
to whatever the Web Ontology group comes up with. "Hopefully" is a trademark of my college mathematics professor, Dr. James Reid. |
Web services usage scenarios (Apr 23rd) The editors have drawn up the following list of Web service usage scenarios
See the document for more detail.
|
Summary
As outlined by the WSAWG the architecture for Web services is strategy based. The hierarchy-building phase of CSFanalysis
serves to turn attributes into tactical steps and evolves into a set of plans.
This is somewhat differerent from either a static architecture based only on patterns alone or even a pattern architecture plus use cases. One gets the sense that that patterns will also be highly useful - especially since there are so many use cases to consider. However, the evolution of subgoals provides the project with direct methods of addressing overall system qualities.
Over all, using CSF appears to be quite helpful and seems able to provide the WSAWG with a robust array of managable subgoals. One question that arises is: In group analysis, is it useful to start to apply CSF hierarchial analysis when the group hasn't as of yet completely agreed on top level goals? There is some risk involved in proceeding too far too fast. But there is also reason to believe that this might prove workable in some respects. As can be seen in the WSDWGs document, when only the top level goals have been considered, there isn't very much detail to go on.
By using the CSF, the WSAWG gets an opportunity to see how feasible and realistic the subgoals are. This may make it easier to come to realistic agreements faster instead of trying to decide only on basis of the undetailed main goals.
About the author
Richard Katz is a life-long software technologist, Editor-in-chief of Java Skyline Magazine. His hobbies include collecting IDEs, software methodologies, application servers, and Prolog-Java interfaces. He is author of Cetus-Links: Object oriented logic programming and Prolog, the Unisys USAS Airline Systems Development Methodology, a number of tutorials and articles on Java Skyline and articles for Byte and PC World magazines.
Resources
For more information see: