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. From a process perspective a variable
can be created that uses any type defined, right ?. 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.
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.
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.
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
|
