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
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
|