> All I meant to indicate
is that even http:// urls which have well understood
network semantics (just like files do and file://
urls) could suffer the same fate. Just as a file://
url is definitely not accessible on another machine, an http url may not be
accessible from another machine (routing, boxing, proxing, etc). And even
validating, if run on the developer box may not produce the same results as on
the runtime box.
Okay, is it not
reasonable to assume that a developer is responsible for ensuring that
references to resources in the form of an http:// url are accessible and
available from wherever needed? I was trying to say: with http:// ref –
deployment code assumes that resource will be accessible; there might be good
reasons for having the resource hosted somewhere; with file:// ref –
deployment code must get the resource and put it into deployment bundle.
> If references are not relative to a project, then
there should be some general utility code along the lines of a resolver.
What would it do?
Pass it an Import and it
gives you the resource. Make it easier on the deployment code.
I think at the end of the day, we are talking about taking some hierarchical
set of files and massaging it into another bundle of hierarchical set of files
that could be on its own understood by the runtime. Since you are using the
word "general" what are the "general" assumptions here ....
?
I am just trying to say: Please,
make it easy for the deployment code; it worries about identifying and getting
all the resources into the bundle that it needs, but it shouldn’t worry
too much about how to get hold of these resources no matter how imports are
represented by the editor.
-- Bruno
From: Michal Chmielewski [mailto:michal.chmielewski@xxxxxxxxxx]
Sent: 25 July 2006 18:40
To: B.Wassermann; BPEL Designer project developer discussions.
Subject: Re: [bpel-dev] Imports
Took a day off yesterday to cool of by the ocean ...
it was 112'F in the "Silly Valley" (which is 44.4'C for you folks in
the old countries).
In Santa Cruz, it was only 72'F (22.2'C) ...
Anyhow ...
Bruno Wassermann wrote:
Hi,
Not much new info, just my two
cents…
> ... I am not sure that
classpath is a good thing and that flattening is good either.
I agree, it would complicate the job of any
deployment code (and it’s complicated enough as it is, in my view :).
> The simplest way I can think of doing this is if
we assume that a project is the unit of deployment ...
A project can be a unit of deployment as can a single
BPEL file (the latter case is important for our users). In the latter case
though the BPEL file/module has information linking it to a particular project.
Absolute URIs in the form of http://
pointing to some resource hosted by some web server are fine for deployment
(given that the resource is actually accessible – validation issue for
user to take care of).
All I meant to indicate is that even http://
urls which have well understood network semantics (just like files do and file:// urls) could suffer the same fate. Just as a file:// url is definitely not accessible on another
machine, an http url may not be accessible from another machine (routing,
boxing, proxing, etc). And even validating, if run on the developer box may not
produce the same results as on the runtime box.
At the end of the day, this becomes bunndle-vs-point problem. That's why I was
leaning to include or point the various resources. I was thinking that perhaps
a distinction could be made file:// and http:// protocol levels, but perhaps it should be more fine
grained - for each resource.
For any other references:
- It
is not unreasonable to expect deployment code for a particular engine to do any
required post-processing of BPEL processes and their resources in order to
satisfy a runtime’s requirements. In our ActiveBPEL integration we have
to do this anyway as we found.
Agreed. So this is the development -> deployable
mapping.
- Deployment
code will have to get a copy of any resources required by a BPEL process that
are not hosted somewhere and store them locally in the deployment bundle. As
long as there is enough information in the imports for the deployment code to
get hold of any imported resources, all is well. There also needs to be a
mechanism to get hold of any imported resources of the imported resources, as I
think James indicated (unless, of course, we can ask users to make sure that
these are hosted somewhere and accessible at runtime).
In BPEL 2.0, the recursive imports are not allowed.
Which means that if you include an import inside an import, it also has to be
in the bpel source file. I think this will end up being terribly limiting, and
I think we ought to have at least a switch for that in the preferences.
But once again, this is a bundle-vs-point problem.
- Absolute
file references are okay for deployment code to get hold of the referenced
resource, but I would be concerned about the effect this has on exchanging BPEL
projects between different developers…
Again, different contexts (of where developers are),
different rules.
It is fair to assume that a particular project is the
starting point for deployment code and so any non-hosted resource should be
accessible via information relative to that project (if I am not 100%
mistaken). For resolving further imports in imported resources, if there is a
mechanism for clients to get hold of these, great!
If references are not relative to a project, then
there should be some general utility code along the lines of a resolver.
What would it do?
I think at the end of the day, we are talking about taking some hierarchical
set of files and massaging it into another bundle of hierarchical set of files
that could be on its own understood by the runtime. Since you are using the
word "general" what are the "general" assumptions here ....
?
-- 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."
_______________________________________________
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."