[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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]