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.
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.
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.
... 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.
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 ...
That's why I think the deployment code will have to adapt/tweak a
project into the form the runtime will understand.
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.
Those are my initial thoughts - I'd
be happy to chat more about this.
james
bpel-dev-bounces@xxxxxxxxxxx wrote on 07/21/2006
06:54:39
AM:
> Hi Michal,
>
> Can you please give an example for what an import in the third
case
could
> look like; what kind of information could be available via the
import
> element for deployment code to work on.
>
>
> Thanks,
>
> -- Bruno
>
>
> -----Original Message-----
> From: bpel-dev-bounces@xxxxxxxxxxx
[mailto:bpel-dev-bounces@xxxxxxxxxxx]
On
> Behalf Of Michal Chmielewski
> Sent: 20 July 2006 21:56
> To: BPEL Designer project developer discussions.
> Subject: [bpel-dev] Imports
>
> In creating automagic imports after partnerLinkTypes had been
browsed
or
> types had been browsed, I am struggling a little in deciding how
to
> write the location attribute of the BPEL import statement.
>
> 1) When imports are for resources in the same project, then it
could
be
> relative, and most importantly relative to the project.
> 2) Absolute imports (from http:// or file:/ urls) are OK as well.
> 3) How to deal with cross project imports ? There are cases where
two
> projects are mapped physically to different directories let's say
and so
> the resource view is just coincidentally rooted at the workspace
level.
>
> It would appear to me that any runtime engines and deployment
mechanisms
> would not necessarily know about the resource mappings of Eclipse.
The
> only bridge between the design world would be the deployment
mechanism
> (the server component). So, I see that it can do its deployables
to
it's
> own liking from the source. Should I just assume that it will do
modify
> the imports then, prior to deployment, or should we do some work
at
this
> level ?
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
--
Michal Chmielewski, CMST, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
|
