[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: Fw: [bpel-dev] Re: Schema questions
|
Hi Michal,
right, any <xsd:schema> element should adds XSD types. But in BPEL there's
no <xsd:schema> element, so I assume you either mean the element in a XSD
document or in-line in a WSDL document. But again, for both a <bpel:import>
element is needed, and though, my understanding is, that XSD types are made
available for the process only with <bpel:import>.
Saying this, I assume the project will use exclusively the location
information in <bpel:import> when resolving references. Optionally I can
imagine a kind of indexer, which looks in a scope, for example the current
classpath, workspace, or whatever, for all artefacts of the known types
(.wsdl and .xsd), opens the document and looks for the targetNamespace.
Then, when trying to resolve for example a XSD type the namespace of this
type is taken to find all artefacts contributing to that namespace and
searching in these artefacts for the referenced type. This or an similar
kind of resolution mechanism would make the <bpel:import> unnecessary for
the resolution, then the given location is really only a hint for finding
dependant artefacts. But without such a namespace resolution mechanism,
which, of course, needs to be designed and implemented additionally, I
think the only way making XSD types available in the BPEL is the
<bpel:import>. And as I know this is the way the current BPEL EMF model
works, right James?
Other comments in-line marked with <ths>.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Michal
Chmielewski
<michal.chmielews To
ki@xxxxxxxxxx> "BPEL Designer project developer
Sent by: discussions."
bpel-dev-bounces@ <bpel-dev@xxxxxxxxxxx>
eclipse.org cc
bpel-dev-bounces@xxxxxxxxxxx
Subject
10.02.2006 00:28 Re: Fw: [bpel-dev] Re: Schema
questions
Please respond to
"BPEL Designer
project developer
discussions."
Thomas Schulze wrote:
Hi Michal,
regarding: "1) Locally scoped partner links may add types to our BPEL
processes."
With 'types', do you mean XSD simple types and XSD complex types? If
yes,
can you explain this in more detail, please? Is this specified
somewhere in
the BPEL Spec?
Yes. Any <schema> element adds types, no ?
Not that I am aware off, and hence this is just a judgment call.
My understanding of BPEL is, that with bpel:imports XSD types are
made
available for the process, not with bpel:partnerLink. For example,
think
about a complexType used only within the process for holding a kind
of
'process state'. If this type is not added by a partner link, because
it is
not used outside of the process, how else is it made available to the
process?
True. There are 2 places where where types can be added: <types> section
and the import statement.
<ths> see above </ths>
>From a process perspective a variable can be created that uses any type
defined, right ?.
<ths> right </ths>
Meaning, if <types> contains a <schema> for nsX and an <bpel:import>
contains types for nsY then both nsX and nsY namespaces ought to be visible
to the process so that a variable must be defined.
<ths> With <types> you mean <wsdl:types>, right? Then I assume the BPEL
will contain a <bpel:import> of the WSDL document which implicitly imports
the XSD types defined in the <wsdl:types> element.
</ths>
But variables can be defined either using message types, simple types, or
element types (from a namespace) and in 2.0 it will also be possible to
define them using complexTypes. However, these type definitions may come
from more then 1 place. And so the whole resolution of types is a little
tricky. Imagine you have the schema for po.xsd (the famous purchase order)
with namespace nsPO. Assume 2 partners would import that namespace in their
PL and you import it in the process as well. You have 3 places where that
PO might come from (let's even assume that they are physically in different
locations, but the content is identical). Assume to make things a little
more funky, that the namespace prefix is different in all of them.
<ths> With 'namespace prefix', do you mean a different namespace, let's say
nsPO1, nsPO2 and nsPO3? Or do you mean when for example referencing a type
from that schema in type="po:PurchaseOrder" the "po:" part, which is later
replaced by the namespace?
</ths>
So at design time, how to show this ? Do you show 1 type for the PO ? Or 3
identical types? If you show some type of browser to browse for types, do
you start at the namespaces as the logical start point, or at the partner
links, then types ? It's a question of type equivalence, in this case
structural type equivalence. This of course gets more complicated if
(let's say) a 3rd partner changes something in their po.xsd (same
namespace) in which case you might have type conflicts in the namespace
nsPO and you have to somehow resolve them or let the user know where the
problem is.
<ths> Depends on the answer for my question above. If the namespace of the
three types is different and only the local name is equal, I would expect
that the editor shows 3 types.
If the prefix is different but the namespace behind the different prefixes
is equal, I would expect that the editor shows only 1 type. Additionally I
would expect an validation error, because in the scope of the BPEL there
are XSD type conflicts. This means, there are two XSD types in different
locations with the same namespace and local name, independent if the
content is identical or not. Reason: The XSD spec says in chapter 2.2.3:
... Here are some examples to illustrate when same names cause problems. If
the two things are both types, say we define a complex type called USStates
and a simple type called USStates, there is a conflict. ...
And the same is true for all definitions in a WSDL. If there are two
portTypes defined in the same namespace there's a conflict, see WSDL 1.1
spec chapter 2.4/A 1.3.
The question is: Is this really the task of a BPEL validation, or is there
a XSD and WSDL validation with can be reused and which checks this for us
and we can concentrating on validating the BPEL?
</ths>
So from the perspective of the designer, yes, I agree it's one global type
system per process. But because you have stitch and aggregate the pieces,
there is I think a little more to be done first.
I looked at the XSD schema model API and it appears that there is no such
feature in there. The schema model XSDSchema comes from a a .xsd document
(parsed via XSDParser for example) or built interactively via the API. I am
just trying to figure out how to approach this given the tools that we
have.
And because bpel:imports are always globally defined at the process,
all
with bpel:import made available types, regardless if contained in a
XSD or
a WSDL, can be used directly after the imports, means for example as
type
for a process variable.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
James Moody
<James_Moody@ca.i
bm.com>
To
Sent by: bpel-dev@xxxxxxxxxxx
bpel-dev-bounces@
cc
eclipse.org
Subject
Fw: [bpel-dev] Re: Schema
questions
08.02.2006 16:18
Please respond to
"BPEL Designer
project developer
discussions."
Second try forwarding this for Michal - the first time didn't show
up.
----- Forwarded by James Moody/Ottawa/IBM on 02/08/2006 10:18 AM
-----
Michal Chmielewski
<michal.chmielewski@oracle
.com>
To
"BPEL Designer project
developer
02/07/2006 09:43 PM discussions."
<bpel-dev@xxxxxxxxxxx>,
James
Moody/Ottawa/IBM@IBMCA
cc
Subject
Re: [bpel-dev] Re: Schema
questions
Michal still has problems with the e-mail to eclispse.org. I am
sending
this to James so that he can post for me for now ... geeeeez.
James Moody wrote:
(Michal had problems sending the original to the list, so I'm
forwarding it
with my reply).
Hi Michal,
So let's talk first about XSD (ignoring both WSDL and BPEL) because
this
might simplify the story somewhat. In the Eclipse XSD model, you can
do
something like the following:
XSDSchema schema = // Let's load a schema from an XSD file here
XSDTypeDefinition def = schema.resolveTypeDefinition(namespace,
localPart);
This resolves the type definition with respect to that schema (taking
into
account imports and includes). I've looked at the implementation, and
it
boils down to is that it iterates over all possibilities and returns
the
first one that matches. So if you have two with the same
namespace/name
pair, you'll get one of them back. You'll get the same one each time
(provided you don't re-order the imports, for example), so I guess
that's
good news anyway. :-)
That's the easy part I think but symptomatically may have the same
problem.
Through some flow of imports or includes a type may be redefined and
it may
be dealt predictably in some way by the schema model API.
Let's say that for a moment that you have something I call a schema
container, SC, which is collection indexed by namespaces. Each
namespace
defines a number of types in it.
Now let's read on.
Add WSDL to the mix and the story is the same - with the addition
that the
WSDL file itself can contain schema definitions which are candidates
for
matching. Then the definition will iterate through the web of imports
and
includes and find the first match.
Yes, but a WSDL can now define types, which potentially can be N
schemas.
Let's assume for simplicity that these schemas in the same WSDL file
are in
fact of different namespaces (ie each <schema> node has a different
namespace).
Then having my SC, the schema container, I can just add SC [ns] to it
for
every ns found. That's the simple case.
Now back up to BPEL. First of all, with regard to your comment about
scoped
partner links below, I don't think this actually affects things -
from the
way I understand it, it's not the *reference* from the partner link
that
makes things in that namespace "available"; instead it's the import.
Since
imports are global and not scoped, then there's no issue with scoping
visibility of XSDs (and WSDLs). Feel free to correct me if I've
misinterpreted. You say that in your implementation you allow the
upward
visibility - in the initial open source implementation we do as well.
There are 2 things here to consider potentially.
1) Locally scoped partner links may add types to our BPEL processes.
Question is, are they global or local (the types) with respect to
variable
declarations in that or outer scopes. Can a higher scope use a type
from
that Partner Link as it's type ? If the type system (and hence schema
container,SC) is global then yes. If no, that's another problem
entirely. I
don't think the spec says anything about this and so for simplicity
our
impl here makes the types global and hence visible from outer scopes
as
well.
2) Each PL can define schemas for a some NS, so let's assume I
already have
ns1 in my schema container, that is SC [ns1] != null.
Assume now that a partner link definition adds some types in that
namespace
ns1. From a global perspective, I wanna say SC [ns1] = SC[ns1] +
newTypes.
If newTypes does not affect any types currently defined in SC[ns1]
then I
am ok. But what if some T1 in newTypes is effectively re-defining a
type in
SC[ns1]? Then either this redefinition is identical (in which case
it
should be silently ignored) or warnings should be issued or a n
auto-magic
pick should happen. Worse, what if M partner links effectively
re-define
the types of a namespace and you have to then deal with the various
add/remove semantics of partner links ? (ie. if I add a link, i
update the
global type system for a namespace, if I remove then I have to remove
some
types from the effected namespaces, that gets a little tricky).
We have seen, however, that this is practically not always the case,
that
types are added to several namespaces from several different
locations and
hence the need to resolve such mess is ours and typically outside of
any
model code API that understands XML schema. Is eclipse model API any
more
helpful here ?
We have logic in our bpel model (specifically in BPELResourceImpl)
that
does effectively what the WSDL and XSD models do - iterate through
the
imports and look for things, returning the first match. So we're
consistent, at any rate. It's actually slightly simpler than the wsdl
and
xsd since we don't have to look in our own file first (since you
can't
define xsd inline in a bpel process). The BPEL spec is notoriously
vague
about how these imports are supposed to behave (it basically says "do
it
kind of like wsdl and xsd do") so we're kind of left on our own in
interpretation of a few points. For example, does an import of wsdl
type
import xsd types declared in the same wsdl file? What if the schema
in the
wsdl file has a different namespace than the wsdl definition - which
namespace should you import? In that case, should it be an XSD-type
of
import or a WSDL-type of import (since bpel does distinguish)? Should
all
imports of XSD types/elements be XSD imports, even if the XSD types
live in
WSDL files? You get the picture.
But imports are typically resolved by the XML schema model code,
because
there are some inherent semantics to that, no ? In other words, if I
have a
schema XML node and give it to such model code I would get back say
an
XSDSchema which I could query for all the namespaces and subsequently
for
the types within that namespace (that were imported). But are there
any
provisions to deal with assembling a list of schemas let's say, which
you
will have when you have more then 1 WSDL in your BPEL process ?
The approach we have taken is to have a concept of the schema
container
indexed by a namespace which does use an underlying schema model API
to
resolve the single schema nodes. But there is a fair amount of code
to
stitch schemas together that come from the WSDLs that happens before
being
handed off to the schema model API.
I was just really curious if the eclipse SDK helped with this or not.
Hope this helps.
james
----- Message from Michal Chmielewski
<michal.chmielewski@oracle.
com> on Wed, 11 Jan 2006 12:26:24 -0800 -----
To:
"BPEL Designer project developer discussions."
<bpel-dev@xxxxxxxxxxx>
Subject:
Schema questions ...
James,
My questions about schema in the Eclipse schema model.
A single WSDL will import or include schema definitions
creating
effectively a type system T1 = (xmlns-1,..., xmlns-N) where
xmlns-? are
namespaces that define some type structures. In practice, you
may have
Tn = (xmlns-n-1,xmlns-n-2,...xmlns-n-M)
With n such type systems defined by each of the wsdl files you
really
have to resolve T which is the ubber type system for the
process which
is basically the union of T1,T2, ...,Tn.
There is no problem if for any i and j, Ti ^ Tj = empty, that
is no 2
wsdl ever import types in the same namespace. The problem if Ti
^ Tj =
non-empty. Then there exists one namespace that is imported in
2
different places. Clearly, you can take a union of the types
and push
them into the ubber type system T. Best case, you have
different types
in these 2 physical definitions, worse case you have a conflict
( same
type defined differently in 2 physical locations).
So my question is about the eclipse XSD model API:
a) Can a container defining T be created (indexed by
namespaces)
b) Can XSD definitions be added to T and the API do type
conflict
detection ?
c) Can the API be instructed to pick one or the other ?
Or do we have to do this ourselves ?
The type system of the process during construction will change
as
partner links are added and removed. So this type of
functionality is
essential. I really need to read more about it but I wanted to
get
feeling as to how much work if any there would be.
From a BPEL perspective, I thought originally this problem
would
compound itself when locally scoped partner links were used.
Simply
because, semantically at least, the partner link is defined
locally in a
scope and has no upward visibility. So should the types be
visible
upward or not ? I don't think the BPEL spec talks about this so
and as
in our implementation we simply allow it.
-m
[attachment "michal.chmielewski.vcf" deleted by James
Moody/Ottawa/IBM] [attachment "michal.chmielewski.vcf" deleted
by
James Moody/Ottawa/IBM] [attachment "michal.chmielewski.vcf"
deleted
by James Moody/Ottawa/IBM]
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
[attachment "michal.chmielewski.vcf" deleted by James
Moody/Ottawa/IBM]
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
