Fwd: Re: [egr-rg] Use Case Repository draft plan
Craig Lee
craig at rush.aero.org
Thu Jul 14 16:22:37 CDT 2005
Forwarded for Bruce Barkstrom. --Craig
>Date: Thu, 14 Jul 2005 11:13:16 -0400
>From: Bruce Barkstrom <b.r.barkstrom at larc.nasa.gov>
>User-Agent: Mozilla Thunderbird 0.8 (X11/20040913)
>X-Accept-Language: en-us, en
>To: Craig Lee <craig at rush.aero.org>
>Cc: eqr-rg at girdforum.org
>Subject: Re: [egr-rg] Use Case Repository draft plan
>
>I think it would be useful to have a context for the use cases we're
>trying to put into
>a repository. My impression thus far is that the use cases being
>considered in developing
>the standards are very simple and highly selected to be easy to make into
>abstract interfaces.
>One could think of the use cases as "prototypical" - and can be made to
>cover a substantial
>fraction of potential real applications. From these selected examples, I
>think the GGF work
>has been highly successful.
>
>However, I think this approach has created three unexpected
>difficulties. First, it is difficult
>to ensure that the interfaces being designed as part of the OGSA are
>"complete" enough to
>work in real systems. Second, while this approach has produced what
>appear to be a "myriad"
>of parts, there appears to be little help for the users of Grid
>infrastructure in how to assemble
>working grid systems. Third, while the use case approach has developed
>component interfaces,
>there is a need to go beyond "grid plumbing" to "grid engineering".
>
>As background, in the UML world, use cases have the function of soliciting
>the objects needed
>for a complete specification of a system. They become particularly
>valuable when the use cases
>illuminate workflows that illustrate how automation of the infrastructure
>can reduce the need
>for human interaction with that infrastructure. From my perspective, the
>use cases we have
>do not fit easily into enterprise workflows -- rather, they appear to be
>snippets of activity where
>it can be difficult for designers to see how the use case fits into a
>larger design. In a UML system
>design, such as the kind of thing one would do with Rational Rose, the use
>cases identify objects
>that exchange messages. In the Grid Services world, the messages are in
>some form of XML.
>Because of the compartmentalized nature of our work so far, it seems
>difficult to ensure that
>when the use cases are placed in this larger context that they will not
>encounter unexpected
>gaps in their interfaces.
>
>One example of this concern appears in a use case I have been working on
>for dealing with
>capacity planning and scheduling of resources. I have a strong belief
>that one of the most
>efficient scheduling protocols is to allow renegotiable reservations of
>resources, with "earliest
>deadline first" allocation of jobs. Based on my work, it looks like this
>scheduling protocol would
>need an object that allocates a pool of CPU's to fulfill a reservation.
>Periodically, another object
>would be allowed to change the allocation to optimize the overall
>efficiency of the total CPU pool.
>Unfortunately, the current WS-Agreement does not deal with resource
>reservations and does not have
>a protocol that would allow renegotiation of a reservation. I know this
>problem is tough, but the
>current use cases don't cover this approach.
>
>The second difficulty, the "myriad of parts" confusion, may be easiest to
>explain with a metaphor.
>Last week, I was at a conference on the Semantic Grid and those of us from
>the grid community
>were sometimes referred to as "grid plumbers". [Maybe this means that we
>should get black T-shirts
>labelling us with that phrase and others that might be associated with it
>- "Difficulties with data
>backup - call the GRID PLUMBERS, RDF: ............." "Not enough plumbing
>to handle your
>computations, google to GRID PLUMBERS ..." and so on.] The metaphor that
>comes to mind
>out of this labelling is that the Grid Services standards are a bit like a
>hardware store's inventory
>of plumbing parts with meticulously manufactured interfaces. Of course
>you don't try to match
>a 3/4" pipe to a 1" elbow. To the extent that this metaphor is
>descriptive, it leads to the confusions
>that show up in the attachment, which I think originates out of the recent
>WWWC conference, rather
>than the GGF meeting.
>
>The third difficulty, then, appears as an outgrowth of the second.
>Specifically, in order to increase
>customer acceptance of Grid technology, we need to provide engineering for
>the assembly of Grid
>systems. By that I mean that we need to provide a set of models in which
>users can find their application
>and which then allow the Grid engineers to provide a more cost-effective
>solution than other approaches.
>Specifically, I think such engineering needs at least four basic models:
> 1. A data storage model - how much data needs to be stored in each
> location
> 2. A computation model - how much CPU time is required in each
> location to complete the work
> 3. A data flow model - how much data needs to be transferred from
> location to location
> 4. A personnel model - how do people spend their time in the
> workflows they need in order to complete
> the work
>For engineering work, we should also categorize the models by the size of
>the jobs to be done and
>try to ensure that the use cases from the applications community cover the
>full range of applications.
>
>As an example of the distinctions that seem to be necessary, we should
>probably separate database transaction
>use cases from workflows that involve flows of small files and separate
>both from workflows that involve large files.
>Likewise, we should probably separate computationally intensive workflows
>from data intensive workflows
>in a way that allows us to make separate engineering judgements about what
>interfaces are needed. I have
>trouble seeing this kind of "Grid engineering" background in the use cases
>that we have now.
>
>Sorry to be so long-winded about this. I suspect I'm in the group that
>feels that we have a long way to
>go in putting together an adequate set of use cases - and that we are
>going to need a different framework
>for describing and using them. In short, what I think we need is the
>following:
> a. Use Cases that belong to a complete design, probably organized by
> workflow
> b. Extension of the use cases to allow quantitative engineering and
> cost analysis based on
> a user's application
>
>Bruce B.
>
>-------------------------------------------------------------------------------------------------------------
>Subject: It's Alan's Turn to Cry
>Date: Mon, 27 Jun 2005 09:03:47 -0400 (EDT)
>From: GRIDtoday <gridmore at news.gridtoday.com>
>To:
>
>
>
>SPECIAL FEATURES
>==============================================================
>
>[ ] M407334 ) It's Alan's Turn to Cry
> By Alan J. Weissberger, Contributing Author
>
> I. Executive Summary
>
> Probably the most important event at this meeting -- an IBM-led
> BOF (Birds of a Feather) session on B2B Web Services Profile -- was
> a non-happening for WS-I. This raises the question of what new work
> WS-I will take on now that the Basic Security Profile (BSP) documents
> are nearing completion. The B2B Profile includes three sets of
> emerging Web service standards: WS Addressing, WS Reliable Messaging
> (without WS Policy aspects) and the WS-I BSP. It was noted that two of
> three WS Addressing documents were nearing completion in W3C (core
> document and SOAP binding). The WS Reliable Messaging standard work is
> just starting this month in the newly formed OASIS WS-RX TC. The BSP
> work should be completed by this fall at the latest (see BSP WG
> report below).
>
> More details on the B2B Profile will be discussed later in
> this article. Let's first review the key accomplishments of the
> various WS-I Working Groups (WGs) as reported at the closing plenary:
>
>
> BSP WG voted to generate a set of new public working drafts, which will
> likely become the final WG approval draft this July. A revised charter
> for the WG will be developed for WS-I Board of Director (BoD) approval.
> It will recommend work on a BSP 1.1 set of documents, which will profile
> the OASIS WS-Security 1.1 documents -- now in Technical Committee Draft
> status. "Fairly comprehensive" BSP 1.1 draft documents will be developed
> this summer. The OASIS WS-Security 1.1 drafts were viewed as being
> "incremental changes" to the WS-Security 1.0 standard, so the WS-I
> profiling work should not take too long. The only other work will be to
> review the Sample Apps and Test Assertion Documents to be completed by
> those respective WS-I WGs. Note that the four existing BSP drafts (from
> May 2005) are available for download and public review from
> <http://www.ws-i.org/>.
>
>
> Sample Apps (SA) WG reviewed and revised its Secure SA
> Architecture document. Target completion date is this July. The SA WG
> had three joint meetings with Test Tools, BSP and Requirements WG. SA WG
> could provide useful feedback on Use Cases and Usage Patterns
> being developed by Requirements WG, but can not generate actual sample
> apps without one or more profiles created (by a new, BoD charted
> WS-I Profiling WG). Test Tools WG was without a chair for this
> meeting. Test tools for BSP interoperability testing are urgently
> needed. Paul Cotton of Microsoft, who chairs the BSP WG, voiced the
> following concern at the closing plenary session: "Does the Test Tools
> WG have an architecture that can properly test the BSP?" There was no
> response to this important question. Requirements WG had a productive
> meeting, but not enough voting members were present to move on any of
> the motions generated. All motions were deferred to the next meeting
> (via teleconference) that achieves quorum. The approach to be taken by
> the WG is to collect usage patterns and validate them against use cases.
> In the absence of sufficient use cases, the WG will ask the opinion of
> users -- most likely via survey. Such a survey was already done to
> prioritize messaging models (Asynchronous Messaging and Reliable
> Messaging were the top two priorities from that survey). In the joint
> meeting with SA WG, it was noted that these usage patterns would be
> developed with a lot of detail but short of protocol specification or
> profiling. The following revised motion will likely be approved at the
> next teleconference (to be scheduled by a new Requirements WG chair):
> The WS-Requirements Group will develop a collection of usage
> patterns that are intended to explore potential interoperability
> issues surrounding asynchronous messaging, reliable messaging and
> security. It will accomplish this task with the following action plan:
>
> 1. Construct a limited number of usage patterns in common commercial use.
>
> 2. Clear definition of terms used in the usage patterns (performed
> in parallel with No. 1 above).
>
> 3. Validation of those usage patterns through best efforts attempts
> to map these patterns to industry use cases. The mapping will
> be accomplished via solicitation to the WS-I membership and to
> customers via their WS-I member vendors.
>
> 4. Explore available specifications and profiles to expose ways
> that these usage patterns may be implemented.
>
> 5. Should there be sufficient doubt concerning interoperability
> of these realized usage patterns, one or more profiling charters may
> be developed for recommendation to the WS-I Board of Directors.
>
> A "Response Routing" usage pattern, submitted by the IBM CIO
> office, was considered. In this case, the response of a request is
> routed to a different entity that originated the request. Static or
> dynamic routing could be used.
>
>
> XML Schema Study Group did not meet. Activity is deferred to
> next week's W3C workshop on the same topic. WS-I members attending
> that workshop were requested to strive for a concrete conclusion
> to properly address the XML schema interoperability problems that
> were identified at the March WS-I Community meeting. Please refer
> to meeting report
> at news.taborcommunications.com/msgget.jsp?mid=352675&xsl=story.xsl
> <http://news.taborcommunications.com/msgget.jsp?mid=352675&xsl=story.xsl>.
> Basic Profile (BP) WG is coming out of hibernation. BP 1.1 with
> errata will be finalized in July. After board of directors approval, it
> will then be submitted to ISO JTC as a new standard. This author asked
> if the board had considered augmenting the BP to include WS-Addressing
> -- now near finalization within W3C. Answer: not yet. That leads us
> to the topic of what new technical work WS-I might take on after
> this summer and the aforementioned IBM-led BOF on B2B profile. II.
> "It's my BOF, I'll Cry if I Want To" [from Leslie Gore's hit song, "It's
> My Party," aka "It's Judy's Turn to Cry"]
>
> Chris Ferris of IBM led a most stimulating BOF on IBM's work
> in creating a Business-to-Business (B2B) profile of emerging Web
> services standards that are or have been worked by open standards
> bodies (OASIS, WS-I, W3C).
>
> While the advantages of Web services for eBusiness {or
> B2B} transactions have been well-advertised, there is very little use of
> it today. Such a B2B profile, if adopted by a critical mass of
> users, could launch a huge new market for Web services. An analogous
> profile for Web services as Grid infrastructure will be considered at
> this week's GG14 meeting in Chicago.
>
> The IBM B2B Profile was developed as part of IBM's "client
> centric profile initiative" for an "on demand" IT operating environment
> (aka IBM Websphere platform). The current conundrum faced by users
> is rampant confusion caused by a proliferation of Web services
> standards and WS* specs (53 at last count). Many of these
> standards/specs are overlapping or competing in functionality (which
> could be the subject of a separate and long article). As a result, users
> are not sure of what WS protocols, specs or standards to use, or ask
> their Web services middleware vendors for.
>
> Microsoft comment from the floor: "We ask customers what scenarios they
> want to enable (versus what specs/standards they need)."
>
> There is a huge recognized value in profiles:
>
>
> WS-I deliverables (BP along with supporting Sample Apps and Test Tools)
> have proven to be invaluable to users and reduces confusion in the WS
> marketplace. The profiles define what's real and implemented by many
> vendors. However, WS-I is now in a holding pattern, with no new
> technical work taken on since the BSP WG was started. As per the summary
> above, that work is scheduled to be completed by this summer.
>
> IBM observes that its customers and industry vertical groups
> are confused. They want to use WS for B2B apps, but they don't know
> how all the WS* specs fit together, which ones they need or how they
> can be combined with (OASIS or W3C) WS standards. The B2B Profile is
> seen as being a means of breaking this Web services industry deadlock.
>
> IBM's client centric profile initiative is separate and distinct
> from the IBM-MSFT WS* workshop process. It involves the following
> action items:
>
>
> Collaborate with clients to understand their business
> challenges requiring standards based solutions. Identify sets of
> standards that address business challenges. Develop profiles and usage
> scenarios articulating the interoperable use of the identified
> standards. Identify solutions, which include client support and
> composability (with other specs/standards) aspects. Use profiles and
> usage scenarios as a basis for product development and services
> engagements. Work within industry groups to establish the identified
> usage scenarios and corresponding profiles as the broadly applied
> standard method. The benefits of this approach are readily apparent:
>
>
> Increased interoperability, productivity and flexibility. Reduced
> risk, time to market, and integration cost. Improved ROI. This
> collaboration process -- between IBM and its customers -- has evolved
> over the last 18 months. The resulting profiles and usage scenarios are
> published royalty-free and provide early implementation support (on
> Websphere). There have been "proof of concept" demos, interop testing,
> and feedback provided to profiles and implementation teams. IBM has
> observed the same Web service requirements across many industries.
> However, Web services policy expressions and assertions have found to be
> industry group-specific.
>
> The IBM Basic B2B Profile (see references below) involves specification
> of all important aspects of: WS-I BSP (4 documents), WS Reliable
> Messaging (subject of several articles by this author), and WS
> Addressing (now nearing W3C standards completion).
>
> Ferris stated that WS-I could take on this work, whenever it chooses to
> do so. He said, "Customers want this work to be done within WS-I, which
> has brand recognition for specifying WS stacks." The IBM B2B Profile
> even used the WS-I profiling template.
>
> To this author, Chris' offer to redirect the B2B Profile work to
> WS-I was a "nick of time" savior for an organization stuck in
> political (board of directors) gridlock and rapidly running out of work to do.
>
> In the ensuing discussion, there was general support for the B2B
> work, but no one suggesting it should be considered now by WS-I at this time:
>
>
> One board member got close to an endorsement (note: all comments
> are anonymously quoted). He stated, "The B2B Profile is very valuable
> work if Web services are to be used for real business applications.
> The work should be done in WS-I or some other open
> standards organization." Another important WS-I player (who also
> chairs a W3C standards group) seemed to make a strong case for doing the
> work in WS-I when he stated, "My company can't implement this if it is
> controlled by IBM -- it could change at any time." But then he added,
> "WS-I will only work on projects that n-1 [board of directors] members
> approve." That seemed to cool things off. An end user in the audience
> chimed in with two thought-provoking questions: "Does WS-I want to
> influence the outcome of end users B2B transactions using Web services?
> If not this, then what else will WS-I work on?" One vendor suggested
> an alternative to the B2B Profile (which this author raised at the
> closing plenary during the BP WG report -- see above): BP 2.0, which
> includes WS Addressing. Another vendor, representing a Japanese
> company, opined that WS-I process may not provide enough visibility from
> start to completion of the project because WS-I mailing lists are not
> open to the public (they are actually only open to WS-I member company
> representatives that have joined that specific WG). So, at one point
> during the discussion, Ferris stated, "It's my BOF and I'll cry if I
> want to." He sensed good support for the B2B Profile work, but that
> attendees seemed to feel WS-I was not the correct venue for the work at
> this time. This raises two important questions:
>
>
> What is a better standards organization; considering that WS-I is
> the only one that deals with interoperability aspects of Web services
> (W3C and OASIS) standards? Will WS-I cease to exist after this fall, as
> no new work has been chartered? Having been involved in Web services
> standards for well over two years, I was hoping WS-I would take on this
> work to enable Web services to realize its market potential in eBusiness
> applications. I was quite disappointed that there was no follow up
> proposal to do this. As I left the room at the end of the BOF, I felt
> like it was "Alan's turn to cry."
>
> References
>
>
> 1. IBM Basic B2B
> Profile:
> <http://www-128.ibm.com/developerworks/webservices/library/specification/w
> s-b2b/>. 2. Understanding the IBM Basic B2B
> Profile: www-128.ibm.com/developerworks/web/library/ws-b2bpaper.html.
> <http://www-128.ibm.com/developerworks/web/library/ws-b2bpaper.html> 3.
> Link to IBM view on organization of Web Services
> standards: <http://www-128.ibm.com/developerworks/webservices/standards/>.
>
More information about the egr-rg
mailing list