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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-uc message

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


Subject: RE: [wsbpel-uc] Re: 1st Candidate examples of deliverables


Title: Message

Hey Harvey,

Great - and yes, you are right, the catalog helps maintain our focus.

 

Re volunteering to help, I am definitely willing - I will follow up with you tomorrow morning.

 

Rand

 

-----Original Message-----
From: Harvey Reed [mailto:hreed@sonicsoftware.com]
Sent: Wednesday, September 24, 2003 12:36 PM
To:
Rand Anderson; 'Sid Askary'; 'Sally St. Amand'
Cc: wsbpel-uc@lists.oasis-open.org
Subject: RE: [wsbpel-uc] Re: 1st Candidate examples of deliverables

Rand,

 

We are all still in agreement. Keep in mind the catalog that we all worked on together, and agreed to use, is structured so that:

 

(a)     The 'objects' that we anticipate to deliver are organized into types, from high-level business types, down to technical xml object types. We can add better visual separators if that will help keep things clear in the readers' minds.

(b)     We can name 'object types' whatever we want. I do not have an opinion for the name of any of the 'object types'. Please propose a set of names!

(c)     It is organized so that one 'object' can reuse other 'objects'. In fact reuse was one of the primary goals of the current catalog.

 

The exercise we are doing this week is to create a first set of use case deliverables. I offered that we should try to deliver at least one of each item, and anticipate there will not be uniform emphasis on each of the items 1-7. Indeed there will probably be a good deal of hand-waving on some of them. The point is that we must deliver something, this week, by Friday, in order that we have concrete deliverables to base future discussions on.

 

Are you volunteering to come up with a draft of deliverables that we need for items #1&2, as well as a naming proposal?

 

Cheers!

++harvey

 

 

 

-----Original Message-----
From:
Rand Anderson [mailto:randerson@macgregor.com]
Sent: Wednesday, September 24, 2003 11:09 AM
To: 'Harvey Reed'; 'Sid Askary';
'Sally St. Amand'
Cc: wsbpel-uc@lists.oasis-open.org
Subject: RE: [wsbpel-uc] Re: 1st Candidate examples of deliverables

 

Hi Harvey, Hi Sid, et al,

Not sure if this is precisely what Sid was after, but I was going to make a similar suggestion. The idea would be to not so much ignore WSDL completely, but rather just decouple items 3-7 from 1-2 fairly explicitly in the organization of our artifacts. This is beneficial as it allows easier re-use of existing non-WSDL-specific requirements use cases, and also lets business analysts who don't know or care about WSDL (or any technology specific mappings) interact with our artifacts without getting pulled into tech-specific issues, etc.

 

I think that this is a theme that Sally was after earlier as well.

 

So the idea would be to have the first artifact - have we solidified on what we are calling it? Use Case? Usage Scenario? something else? - focus on just the first two elements that you list below, Harvey. Let me interject at this point that I would propose calling these two elements 'Actors' (was 'Entities') and 'Services' (was 'Actors'). [I'll follow-up separately on this, worth a separate thread, I know there are some concerns about adopting particular vocabs, etc]. So the starting point for any requirements statement is a description of the use expressed in terms of actors consuming/using services.

 

Then, the additional artifacts (3-7 and maybe more) would be developed and associated with the requirements statement.

 

HTH,

Rand

-----Original Message-----
From: Harvey Reed [mailto:hreed@sonicsoftware.com]
Sent: Wednesday, September 24, 2003 10:28 AM
To: 'Sid Askary';
'Sally St. Amand'
Cc: wsbpel-uc@lists.oasis-open.org
Subject: RE: [wsbpel-uc] Re: 1st Candidate examples of deliverables

Sid,

 

This is as good a place/time to discuss as any.

 

Considering that the whole point of BPEL is to orchestrate operations as defined in a WSDL, I am puzzled as to why WSDL is out of scope. However, it could be that I am misunderstanding what you are advocating. If you can offer up a concrete sample of use case deliverables that will help de-mystify issues. Even a rough skeleton will add lots of value J

 

Is there any way to kick out such a sample soon, so together, we can comment, critique, and iterate to produce deliverables by this Friday?

 

Thanks so much!

 

++Harvey

 

 

-----Original Message-----
From: Sid Askary [mailto:saskary@nuperus.com]
Sent: Tuesday, September 23, 2003 5:57 PM
To: Harvey Reed;
'Sally St. Amand'
Cc: wsbpel-uc@lists.oasis-open.org
Subject: [wsbpel-uc] Re: 1st Candidate examples of deliverables

 

Harvey,
I am working on a sample as we speak.  I would like to discuss the list that you have at some point.  For example, as per my email, I think examples are not use cases.  Therefore, schema's, WSDL, etc. are not initially in scope.

Sid.

At 02:44 PM 9/22/2003, Harvey Reed wrote:

Sally, Sid,

 

The proposal is to deliver candidate examples of deliverables to the UC group by COB Friday. Lets say by 5pm ET. Per what we have discussed prior, I think the list is:

 

1.      Entities with descriptions, that own

2.      Actors (or better name) which are web services, that expose

3.      WSDL to describe operations that exchange messages that have

4.      Schemas, all of this used by

5.      BPEL use case explanative text, (using template?)with

6.      Executable BPEL, and possibly,

7.      Abstract BPEL


 

Lets also take into account issues/concerns that Sid is writing up (please reply and paste in), and any thoughts from Sally. Once we agree on the list of deliverables, we can make outlines of the deliverables we can agree on, then fill one coherent example in and submit back to the UC for comment, then the TC for demonstrating progress.

 

So the next action item is for Sid to reply with his thoughts that he is writing up, and we can drive from there&

 

Harvey Reed

Technical Product Manager

Sonic Software

www.SonicSoftware.com

781-999-7027

 



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