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


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bpel message

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

Subject: RE: [sca-bpel] Issue 18 proposal and next week's call

For sake of convenience I have attached a pdf version of Mike R's proposal with added line numbers.

Since the call last week I took a step back to try to understand what we are trying to define,
which would help me elucidate my concerns about the proposed text. Words like Runtime and
generation in the same rule make me very nervous. Initially I was trying to find an alternative to
the word generate that might more accurately reflect what a runtime has to do, but finding a
substitute is not easy. 

To me the problem starts at the beginning of section 2 (lines 180 thru 197). This  text introduces
the concept of a component type and ends on line 197 by saying "The Component Type MAY be generated
from a WS-BPEL process definition by introspection." Also line 217 has a similar sentence on
generating a component type

However nowhere does it state when the component type should be generated, and Assembly doesn't say
much on this subject. 
I have always assumed that in order to assemble and configure, one needs to know the component type
at design time prior to any runtime involvement. In this case, one must know the services and
references of a BPEL implementation in order to do design time wiring. Whether generated or not,
the rules of section 2.1 should be obeyed e.g. it would be invalid to define a component type with
a reference, if the related BPEL activity is a receive. Furthermore, one is also allowed to define
a component with a BPEL implementation without the need for a component type, and in this case as
well the rules of 2.1 should be obeyed IMHO.

Without a common understanding of the use cases we are supporting, and an understanding of where in
the lifecycle artifacts are needed, finding  the right words in section 2.1 is going to be tough.
What I think we need to do is define the relationship rules between BPEL and Assembly, regardless
of whether it's a component or a component type, and then decide at what point in the lifecycle the
definitions must be available, whether they can be generated or not, and whether we have to mandate
what generates them. 

I propose we start the discussion on Thursday by reviewing the use cases we are supporting and any
assumptions we have, before diving into the wording details.


> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
> Sent: 25 July 2008 23:00
> Subject: [sca-bpel] Issue 18 proposal and next week's call
> As promised on this week's I'm sending this email.
> Issue 18 proposal from Michael is located at: 
> http://lists.oasis-open.org/archives/sca-bpel/200806/doc00001.doc and 
> was sent in the email at 
> http://lists.oasis-open.org/archives/sca-bpel/200806/msg00002.html
> This is the proposal that is called revision 5, but should be really 
> called sca-bpel-1.1-spec-cd01-18proposal.doc (or something like that).
> Homework: please read this proposal and send 
> feedback/opinions/changes/alternate proposals by email before next 
> week's call.
> We only have one issue to discuss next week and that is issue 
> 18. This 
> issue along with Michael's proposal (and other proposals, if 
> any) will 
> be included in the agenda for next week.
> After next week's call we'll go into aestivation for all of 
> august. It 
> would be nice if we could resolve issue 18 as it applies to 
> section 2.1. 
> If we resolve it for 2.1, we can then assign an AI to the editors to 
> take that forward to the other sections.
> Thanks.
> -Anish
> --
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS 
> TC that generates this mail.  Follow this link to all your 
> TCs in OASIS at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 


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