[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [bpel-dev] Re: Schema questions
|
Hi James, Michal,
what happens if the BPEL imports the two XSDs with conflicting type or
element definitions in another order than the WSDL? I would assume that
this results in a conflict in BPEL, for example when assigning a BPEL
variable of the type from one XSD to a part in a WSDL message of the type
from the other XSD.
Is the resulting requirement for the editor to enable the user to edit and
order the imports, so the user will be able to fix that problem without
opening the BPEL with a text based editor and changing the order of the
imports?
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
[bpel-dev] Re: Schema questions
31.01.2006 22:49
Please respond to
"BPEL Designer
project developer
discussions."
(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. :-)
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.
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.
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.
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
