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] Q: process category?


Ron,
 
I am confused. Can I ask a few questions to better understand your requirements?
 
Let's try to take a concrete example: let's imagine that we have a BPEL process implemented within a file called LoanProcess.bpel.
 
Let's imagine that one of the complex context files associated with this BPEL process is a file that contains a static mapping between partnerLinks and physical end point locations/bindings.
 
Let's assume that does 2 files are stored in separate repositories.
 
Let's assume that there is a BPEL directive that requires all tools to generate a new guid each time the file is saved to disk.
 
How does this help you link the bpel process to the endpoint location context file? Unless all the repositories that you are using are UUID-aware and use the UUID as part of the name, it seems to me that the UUID does not really help.
 
My concern is that this UUID gets in the way of naming and versioning and in a way that it too automated and too intrusive.
 
Would you happen to have a specific example about how an automatic UUID generation would be useful?
 
Thank you,
 
Edwin
 


From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Thursday, September 04, 2003 7:06 PM
To: edwink@collaxa.com
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Q: process category?

Edwin,

Edwin Khodabakchian wrote:
Hi Ron,
 
You are assuming that the deployment descriptor and the BPEL artifact are always committed together to their repository. It that case why wouldn't you use a more local addressing scheme to create a link between those 2 assets (see web.xml, ejb.xml etc...).
I think we should make as few assumptions about the deployment implementation as possible. I assume that the deployment system will need to maintain a context, separate from our BPEL artifact, but making reference to it in some fashion. Why should everything exist in a single repository? The BPEL could well come from a repository of standard processes; the WSDL from a UDDI registry, and the deployment environment data from a shrink-wrap-ware rules engine & database, all being managed (and updated) by separate organizational entities. The point being that we can assume very little about the deployment infrastructure.

We can make similar statements about design-time infrastructure.

Given the lack of  convenient simplifying assumptions, are there any requirements that a design- and/or deployment-time implementation might have that BPEL can assist with? More generally, is there a way we can assist unknown tools in maintaining complex contexts that include BPEL, without becoming overly coupled to those contexts?

The only answer that comes to my mind is giving BPEL artifacts a unique identity, that can be used for referring to, identifying and distinguishing such artifacts. It isn't much, but gives a standard mechanism for those external contexts to exploit. If given that it (uuid)  is a standard feature of BPEL, then standard context types can potentially be defined, giving us the opportunity to link BPEL to future standards-based context definitions.
 
You are also assuming that the versioning scheme that each vendor will support will be able to impose nicely on this auto-increment UUID scheme. I think that it will create more confusion. In a real life scenario, the developer will be exposed to his CVS revision, deployment unit version and UUID revision....each have their own rules of change.
I have obviously done a bad job of explaining this notion; my apologies. I hadn't meant to imply any linkage between versioning and the UUID. I had imagined a much more modest scheme, where the process editing tool would provide auto-uuid update. If this were somehow linked the version control system, confusion would be sure to reign, as you rightly point out.

I had not meant to suggest any linkage to the design-time version control; we cannot (and should not) even assume that version control is being used.

Cheers,
-Ron



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