[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: Fw: [bpel-dev] Re: Schema questions
|
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?
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?
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
