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: [wsbpel] Do we need the createInstance attribute?


I think you should acknowledge that this is more than a change of element vs attribute.  If I am the person charged with maintaining the process Frank described, I will be infinitely happier moving the createInstance attribute around (indirectly through some tool) than having to think through control flow changes.  Note that once instantiation occurs all the initial activities are on an equal footing.
 
Of course, to be fair, the onus of the control flow change actually shifts to the sources sending the messages since messages from the non-instantiating sources are in danger of being lost if they are sent prematurely ;-)  But this occurs regardless of how the process is modeled -- it simply states the difficulty of achieving a rendezvous of multiple independent senders at a single instance without using the "multiple start activities" semantics.  
 
 

________________________________

From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Fri 10/31/2003 3:07 PM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Do we need the createInstance attribute?



+1
----- Original Message -----
From: "Eckenfels. Bernd" <B.Eckenfels@seeburger.de>
To: <wsbpel@lists.oasis-open.org>
Sent: Friday, October 31, 2003 3:01 PM
Subject: RE: [wsbpel] Do we need the createInstance attribute?


Hello Frank,

I dont have a problem with changing the control flow, if the Business
Process changes. After all changing an attribute or changing an eleemnt is
not that much different. Both requires to redeploy the process. In fact I
think it is more intuitive to use the flow of control also at the beginning
of an process, and not introduce otherwise new concepts.

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de


-----Original Message-----
From: Frank Leymann [mailto:LEY1@de.ibm.com]
Sent: Friday, October 31, 2003 9:30 AM
To: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Do we need the createInstance attribute?



Assume some sort of auction business process.  It has "start activities"
that are linked to sellers and buyers.

Assume further, you only want a seller to instantiate a new process
instance.

Today, you can model this by having the seller and buyer activities as
start activities, and only the seller activity has createInstance set to
YES.  If we drop this attribute, you have to specify a control flow
dependency that says that the seller comes first, then the buyer - fine.

Now let's imagine that your business policy changes, and you want only
buyers being able to instantiate new process instances.

Without the createInstance attribute you have to change the structure, i.e.
control flow, of the process model. You have to specify now the buyer comes
first, followed by seller.  If we keep the attribute, you simply change the
values of createInstance accordingly without any impact on the control flow
dependencies.

Next assume, that your business policy changes, and you want to allow both,
sellers and buyers to instantiate processes. ...and so on...

And, of course, it's easy to explode complexity and sketch a process model
with N start activities that allow for (2**N)-1 different settings of
createInstance attribute values.  It's very easy to change the attribute
values to reflect the possible (2**N)-1 different "initiation policies"
without having to change the control flow, but it is quite an exercise to
specify the control dependencies that reflect this set of "initiation
policies".

This is what I had in mind when writing that the createInstance attribute
provides for flexibility in instance creation policies. Sorry for having
been so terse...

Regards,
Frank

-------------------
Prof. Dr. Frank Leymann, Distinguished Engineer
IBM Software Group
Member, IBM Academy of Technology

Phone 1:  +49-7031-16 39 98
Phone 2:  +49-7056-96 50 67
Mobile:  +49-172-731 5858
--------------------





Please respond to <ygoland@bea.com>

To:    Frank Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org>
cc:
Subject:    RE: [wsbpel] Do we need the createInstance attribute?


I don't really follow. How would createInstance make a chance in instance
creation policies better or worse? What sort of instance creation policy
change are you thinking of?

> -----Original Message-----
> From: Frank Leymann [mailto:LEY1@de.ibm.com]
> Sent: Thursday, October 23, 2003 11:20 PM
> To: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Do we need the createInstance attribute?
>
>
>
> I am very much in favour of keeping 'createInstance'.  It provides
> flexibility by allowing to change instance creation "policies" without
> having to apply surgery on the process model required in case
> we ban that
> attribute.
>
> Regards,
> Frank
>
> -------------------
> Prof. Dr. Frank Leymann, Distinguished Engineer
> IBM Software Group
> Member, IBM Academy of Technology
>
> Phone 1:  +49-7031-16 39 98
> Phone 2:  +49-7056-96 50 67
> Mobile:  +49-172-731 5858
> --------------------
>
>
>
>
>
> To:    ygoland@bea.com
> cc:    "'Satish Thatte'" <satisht@microsoft.com>, "'Wsbpel@Lists.
>        Oasis-Open. Org (E-mail)'" <wsbpel@lists.oasis-open.org>
> Subject:    Re: [wsbpel] Do we need the createInstance attribute?
>
>
> Yaron Goland wrote:
>
> >I think an editorial change that describes 'createInstance'
> as a marker of
> a
> >start activity, explains that it is redundant and then
> describes why it is
> >there anyway should do nicely. Can we add that to the list you are
> >maintaining of things for the editors to do?
> >
> Does this really answer the original question you posed? Is the sample
> process fragment you supplied considered illegal?
>
> I can easily imagine someone trying to exploit such a "feature" if it
> was not explicitly banned. Borrowing from your example:
>
> <process>
>    ...
>    <flow>
>       <receive partnerLink="A" createInstance="yes".../>
>       <receive partnerLink="B" createInstance="no".../>
>    </flow>
> </process>
>
> This could be used by partner B as a kind of polling
> mechanism to see if
> partner A has done his thing yet. Kind of an event handler for process
> instances that don't exist. Useful for non-deterministic (parallel)
> sections of a choreography.
>
> Do we wish to support this usage, or ban it? I think we need some
> explicit wording one way or the other.
>
> -Ron
>
>
>
> To unsubscribe from this mailing list (and be removed from
> the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
ave_workgroup.php
.







To unsubscribe from this mailing list (and be removed from the roster of
the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup
.
php.



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.







To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.





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