Re: [bpel-dev] Imports

[James Moody <James_Moody@xxxxxxxxxx>]

bpel-dev-bounces@xxxxxxxxxxx wrote on 07/21/2006 02:22:28
PM:

> James,
> 
> Good points. More inline.
> 
> James Moody wrote: 
>         Hi all, 
> 
>         First, some interesting quotes
from issue 7: 
> 
>         "A <bpel:import> import
element will be interpreted as a hint for BPEL
>         processors. In particular, processors
are not required to retrieve the
>         imported document from the specified
location." 
> 
>         ""location": where
to find the imported information" 
> 
>         They specifically leave the location
kind of vague - other than 
>         saying it's a URI, they obviously
don't address issues that we're 
>         describing (which is probably
a good thing). 
> 
>         If I could make some observations
from a (not-so-)theoretical position... 
> 
>         1. Michal's point about the fact
that during runtime and deployment 
>         the structure could be very very
different than in the Eclipse 
>         workspace is well-taken. 
>         2. We should never use Eclipse-specific
"platform:/" URIs in these imports. 
> Agreed.
>         3. While
absolute http:// imports are okay (since these won't change
>         regardless of where you are),
I believe absolute file:// urls are 
>         not. Especially when you consider
that when you package this process
>         up in an ear or a zip and deploy
it on the runtime, you may not even
>         be on the same machine as during
authoring time. 
> Same could be said about the http:// imports,
albeit the level at 
> which this becomes an issue is a little higher or different. 
> This gets complicated if the imports include other imports as well.

Regarding imports including other imports, I thought
that there was recently an oasis resolution that clarifies that imports
are *not* to be treated as transitive (or maybe that was something we discussed
earlier on the mailing list). Although the current model treats them as
transitive, this is something we'd need to fix. But I don't know if that
changes the statements above.

>         4. Relative
uris seem to be the best approach to locate files that 
>         are in the same "project"
at authoring time. If we consider the unit
>         of deployment to be a project,
for example, then these relative uris
>         should also be valid during deployment
or at runtime. 
> Relatives within the same project are OK since
once the project maps
> onto a hierarchical physical structure like a file system then that
> is well understood on many platforms and follows well aligned semantics.

Yup, agreed.

>         5. The cross-project
imports are interesting. First, let's imagine 
>         that we will use relative uris
to find a cross-project referenced 
>         file. Let's also imagine that
our project dependency chain gives us 
>         something very similar to a "classpath",
which we will use to locate
>         these things. Given a workspace
structure as follows, where A and B 
>         are projects: 
>         <workspace root> 
>                 A
>                  
      a.bpel 
>                 B
>                  
      b.wsdl 
>         Then assuming that A properly
pre-reqs B, you should be able to have
>         an import in a.bpel with a location
of "b.wsdl" since the classpath 
>         flattens everything out into a
single location. Similarly, if we had 
>         <workspace root> 
>                 A
>                  
      a.bpel 
>                 B
>                  
      folder1 
>                  
              b.wsdl 
>         Then the import from a.bpel should
be "folder1/b.wsdl". 
>         
>         If we assume this is okay, then
we have two issues: 
>         
>         A. In the tools (i.e. in Eclipse
during authoring time), how do we 
>         make the model understand that
it should look in referenced projects
>         for required files? 
>         B. During deployment and at runtime,
how do we make the model 
>         understand where it should look
for required files? This is 
>         different than (A) because at
deployment time, both A and B could be
>         contained in ejb module jars inside
an ear file, for example. Or 
>         maybe A and B are each zipped
up and placed inside a master zip 
>         file. The point is, depending
on how deployment works there could be
>         different ways of "finding"
these relative things. 
> Then as you say you will have to have that notion
in  both runtime 
> and design time of what that classpath is and I think you could get
> into "classpath" issues - same file name in 2 different
projects for example.

Agreed.

> 
> ... I am not sure that classpath is a good thing and that flattening
> is good either. I am not sure how many "classpath" issues
you have 
> solved in your lifetime, but I have done enough to last me few years.

<g> I'll take your word on that.

> That's why I am leaning towards a design time vs. runtime mappings.
> 
>         Also note that the bpel model
is not the only one with this issue. 
>         XSDs can import other XSDs, and
WSDLs can import other WSDLs as well
>         as XSDs. These face exactly the
same issue both during authoring and
>         during deployment. 
> 
>         We've observed that in the case
of the XSD and WSDL models, it's 
>         possible to replace the default
uri resolved with one of your own. 
>         In this way, you can implement
whatever strategy you like for 
>         locating files, and you can do
so differently in tools and in 
>         runtime if you like. 
>         
>         In the case of the BPEL model,
we have purposely planned for this 
>         sort of scheme (of course, we
faced it in IBM WebSphere Integration 
>         Developer). There is a single
point in the BPEL model where this 
>         resolution can be intercepted.
Notice that we have classes named 
>         WSDLImportResolver and XSDImportResolver.
Here is where we should 
>         put workspace-specific logic for
the resolution of these imports in 
>         whatever way makes sense for an
Eclipse directory structure. What we
>         need to do (and as the comment
in BPELResourceImpl.
>         getEObjectExtended() notes) is
provide an extensible mechanism 
>         whereby one can replace this logic
either (a) in their product, if 
>         the default behaviour doesn't
make sense for them, or (b) in the 
>         runtime, where the layout almost
certainly differs. This should be 
>         as simple as introducing an extension
point which allows one to plug
>         in their own ImportResolver. 
> But the assumption here is that the "runtime"
will use the EMF model
> and sizable portion of the code to slurp the BPEL code and its 
> dependencies into some runtime model. That may not be the case everywhere
... 

Very true.

> That's why I think the deployment code will have to adapt/tweak a
> project into the form the runtime will understand. 

Yeah - this is getting to the heart of the problem,
which is that the bpel specification (probably intentionally) doesn't specify
how imports should look (other than them being uris) or how they should
be interpreted. So basically other than the obvious cases (i.e. fully specified
absolute http or file URLs) the structure and behaviour could be said to
be unspecified, and likely to differ across different tools and runtimes.

> The simplest way I can think of doing this is if we assume that a
> project is the unit of deployment ...
> 1) Anything in the project that has relative references is OK.
> 2) Absolute URI references (http:// or file://) can be left as are
> *or* could be asked to be brought into the bundle so that there is
> no resolution issue at runtime. 
> 3) References to documents in other projects are brought into the
> deployment bundle. If included documents are present in such 
> references, then the follow (2) or (3).
> 
> Such approach will use the deployment bundle as self contained, 
> structurally understood entity. The only possibility of outside 
> references would be links  (http urls or file:// urls). But the
> option to bundle those  is available at deployment.
> 

This would indeed ensure the deployment bundle is
self contained. However, imagine that you have one project that you're
treating as a "library". In it are all the XSDs and WSDLs that
are shared across all your other projects (i.e. used by all of your processes
in, say, 5 different projects). One of these XSDs is your enterprise-wide
(or industry-wide) XSD which is, say, 5 MBs and contains hundreds or thousands
of type definitions. You really don't want to have to have 5 copies of
this on the server, especially if you need to deal with versioning or updating
it - could become a maintenance nightmare.

On the other hand, perhaps this decision could be
left to the runtime glue and even could be different depending on the runtime.
If we know it's a runtime which can understand cross-project imports, great.
If not, we bundle a single deployment unit. Or something like that - I'm
mostly making this up as I go along.

james