OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Requirements and Scope Documents?


[Reposting the WSBPEL TC mailing list...]

John,
I understand that we have a specification.  As for the requirement, the primary 
purpose would be to help clarify and guide the discussions.  A concise 
requirements document (some of whose content can be extrapolated from the 
current specification) could serve as a basis for answering some of the 
current – and perhaps future – questions regarding intent, assumptions, 
precision, accuracy (and conversely, ambiguity), complexity, convenience and 
completeness, etc. of the effort.  

This could also help to classify and manage business and technical concerns so 
that “interoperability” and “modeling” or “behavioral equivalence” 
and “reduction” will be discussed in the proper context.

As for the scope, the charter states only the “inclusion” of the following:
a.        Sequencing of process activities, especially Web service interactions 
b.        Correlation of messages and process instances 
c.        Recovery behavior in case of failures and exceptional conditions 
d.        Bilateral Web service based relationships between process roles 
Whereas the specification (pdf version 1.1. May 5, 2004) states “exclusion” of 
the following:

1.        Partner service description and process deployment. (sec. 7.2 near 
top 
of p.35)
2.        Notions of service policies, endpoint properties, and message 
context. 
(sec. 8.1 near bottom p.36)
3.        The achievement of distributed agreement is an orthogonal problem 
outside the scope of BPEL4WS, to be solved by using the protocols described in 
the WS-Transaction specification. The need to compose WS-transaction with 
BPEL4WS is recognized. (sec. 13.2 near the bottom of p.71)

It does not seem entirely clear if the two sets are mutually exclusive.  
Additionally, one can neither assume that together the sets are complete, nor 
arrive at a common reasoning and understanding of the mechanism for 
current “inclusion” and future “exclusion” classification.

In short, having these documents will enhance the quality of the effort and 
help expedite the process.  

What do you think?

-- Sid Askary.


Quoting John Evdemon <jevdemon@microsoft.com>:

> [Copying the WSBPEL TC mailing list...]
> 
> Sid,
> 
> Why are these documents needed?  What purpose will they serve?
> 
> Since we are revising an established specification I'm not sure why a
> requirements document is needed.  The charter also defines our scope in
> fairly simple terms.  
> 
> Can someone clarify the need for requirements and scope documents?
> 
> Thanks!
> 
> JohnE
> 
> 
> 
> > -----Original Message-----
> > From: saskary@nuperus.com [mailto:saskary@nuperus.com]
> > Sent: Tuesday, June 24, 2003 1:38 PM
> > To: Diane Jordan
> > Cc: Yaron Y. Goland; James Bryce Clark; John Evdemon
> > Subject:
> > 
> > Diane,
> > As for the agenda for tomorrow, could you please add the motion for a
> > requirements and scope document ( as per use case and reqs joint conf
> > call)?
> > 
> > Thanks,
> > 
> > Sid.
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]