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?


Edwin,

    I think we are proceeding in different directions: you are thinking of the implementation of supporting tools for authoring BPEL (and rightly so; Collaxa is on the leading edge here), while I am worrying about the need to standardise external context information that such tools may construct, so that such contexts can be exchanged along with the concrete artifacts like the WSDLs and the BPELs.

    An external context that needs to keep a reference to LoanProcess.bpel needs to identify it, yes? As you pointed out before, local techniques can be used to do this. This is common practice, except in areas where the need to exchange such context information has created the need for de jure or de facto definitions of such external contexts. (A lot of the WS-* specs are, in part, attempts to define standardised contexts at various levels in the WS stack.)

    A standardised approach to external context can provide many benefits, but obviously limits what we can do in terms of "local techniques" for identifying artifacts; certainly we cannot assume the presence of version control systems, repositories, or even a file system! In this light, I believe there is a weakness in the existing BPEL spec, in that it doesn't provide an internal standard concept of process-type identity that can be utilized by standards-based external context definitions.

    Another example that is, perhaps, closer to home is that of abstract processes and executable processes that purport to conform to a particular abstract process. The current picture is that the design-time tooling will maintain an external context that keeps the relationship between, say, abstract process A and executable process B, which conforms to A. That is a perfectly fine thing for a design tool to do, and doubtless it can exploit its own local repository, version control etc. to accomplish this. However, such a context is not portable, and the perfectly reasonable need to exchange process definitions with other tools (say, an analysis tool) may easily run afoul of the inability to exchange information about the relationship between A and B. This may become so annoying that the makers of users of  such tools may band together, form a TC at an appropriate standards-setting or industry organisation, and try to invent a standard mechanism and rid themselves of this problem once and for all. In such a situation, no "local techniques" for referring to BPEL documents could be exploited; this is where a clear-cut notion of  identity would be helpful.

    I'm sure that many useful standard external contexts can be crafted that would involve BPEL, which as an orchestration language will find a home in EAI situations which usually involve many different external contexts (e.g., UAN). We certainly don't want to be in the situation of adding new properties to BPEL to support them all directly. (Non-standard extensions of this sort are permitted, but as they are non-portable that have less value.)

    My proposal for a UUID was a straw-man, and, truth to tell, stolen directly from BPSS. We should only require that the identity of the process change when there is some possibility that two different versions of the same entity could be confused. This could be done by our mythical emacs/vi user, in a manual fashion, or more automatically by tools. (This no more onerous than maintaining unique IDs for ebXML CPA instances, for example) We should make it clear that process-type identity is not to be confused for version control, and that the identity is meant for external use only.

    Is that any clearer? I feel the distinct need for a whiteboard and some hand-waving, but this isn't the right medium...

Cheers,
-Ron

Edwin Khodabakchian wrote:
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]