-- Bruno
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."