You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by Arthur Ryman <ry...@ca.ibm.com> on 2006/04/01 18:54:26 UTC
Re: Woden & WSDL 1.1
Matt,
My suggestion is not for the converter. It's for using the WSDL 2.0
Component Model as a replacement for the WOM in Axis2. At present, there
are a lot of things in WSDL 1.1 that can't be expressed in WSDL 2.0 as you
have enumerated in your work on the converter. However, there is a huge
area of overlap so most of WSDL 1.1 can be expressed in terms of the
Component Model. To express the others, extensions are needed, e.g. for
rpc/encoded.
The goal is to use the Woden Component Model as the internal
representation for WSDL in Axis2 and to be able to serialize it as both
WSDL 2.0 or WSDL 1.1. Any component model instance could be serialized as
WSDL 2.0 using the extensions. A subset of instances could also be
serialized as WSDL 1.1.
This means that Axis2 can still support "legacy" WSDL 1.1 documents via
Woden. Otherwise, Axis2 would need 2 models.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Matthew Duftler <du...@us.ibm.com>
03/31/2006 04:37 PM
Please respond to
woden-dev@ws.apache.org
To
woden-dev@ws.apache.org
cc
Subject
Re: Woden & WSDL 1.1
Hi Art,
Sorry for taking a while to respond to this; I'm playing a bit of email
catchup.
I'm not quite sure I see why adding the ability to convert 1.1 documents
into 2.0 requires new extensions (I haven't really thought much about
supporting rpc-type WSDL 1.1 docs, though).
>Further to me previous note, we'd need WSDL 2.0 extensions to capture
most
of these differences.
Why does Woden need to capture most of these differences? As long as the
conversion/mapping from 1.1 to 2.0 is reasonable and public, why would you
need to maintain the original representation? Actually, if you are going
to
define extensions to represent all the original 1.1 semantics, why
wouldn't
you just wrap the entire original 1.1 syntax, and use that as a 2.0
extension? Either way, you need to navigate an additional representation,
no?
Thanks,
-Matt
Arthur Ryman
<ryman@ca.ibm.com To: woden-dev@ws.apache.org
> cc: woden-dev@ws.apache.org
Subject: Re: Woden & WSDL
1.1
03/17/2006 05:34
PM
Please respond to
woden-dev
Matt,
Nice list. I think the W3C once started a document that outlined all the
differences. I don't rememeber what happened to it, but I think it would
be
a very useful thing to have.
Further to me previous note, we'd need WSDL 2.0 extensions to capture most
of these differences.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Matthew Duftler <du...@us.ibm.com>
To
03/17/2006 04:45 PM woden-dev@ws.apache.
org
cc
Please respond to woden-dev@ws.apache.
woden-dev@ws.apache.org org
Subject
Re: Woden & WSDL 1.1
Hi Arthur,
>The other main mismatch is that a WSDL 2.0 <service> implements a single
<interface>. In WSDL 1.1, a service can contain endpoints ( <port>'s) that
im>plement arbitrary interfaces (<portType>'s). To map WSDL 1.1 to WSDL
2.0, you'd have to split up a <wsdl11:service> into several
<wsdl20:service> >elements. However, we should preserve the relation
between these split up services so we can generate the same WSDL 1.1
again.
This could also be >handled with an extension.
In the course of creating the conversion code I came across quite a few
constructs that are handled differently in 1.1 vs 2.0. I created a short
list with some notes of how I handled the issues:
Definition of service components:
- In 1.1, <service>s can have multiple <port>s, with each <port> bound to
a
different <portType>.
- In 2.0, <service>s are bound to one <interface>.
- Notes: If a service is encountered that has ports bound to more than one
portType, a service is generated for each referenced portType. Each newly
generated service has the suffix "_n" appended to its name, with n
increasing from 1 until the name is unique.
Overloading of operation names:
- In 1.1, <operation> names are permitted to be overloaded. When referring
to overloaded <operation>s from <binding>s, <operation>s are uniquely
identified by using the names of the <input> and <output> elements in
addition to the name of the <operation>.
- In 2.0, <operation> names must be unique within an <interface>.
- Notes: Any operation name found to be overloaded has the suffix "_n"
appended to it, with n increasing from 1 until the name is unique.
targetNamespace requirements:
- In 1.1, the targetNamespace attribute of <definition> is optional; if it
is not specified, all references to items defined within the document must
be done without prefixes, and the default namespace must be set to "".
Also, if no targetNamespace is specified, no top-level items defined
within
the document can be referred to from other WSDL documents.
- In 2.0, the targetNamespace attribute of <description> is required.
- Notes: There is a -targetNS command-line argument that allows the user
to
specify the targetNamespace to be used. If the source 1.1 document does
not
specify a targetNamespace, this argument is required; if the source 1.1
document does specify a targetNamespace, the argument serves as an
optional
way to override the specified targetNamespace. The targetNamespace
replacement will propagate via a generated include, but not via a
generated
import.
Ordering of top-level elements:
- In 1.1, the children of <definition> may appear in any order (even
though
the schema says otherwise).
- In 2.0, the order is strictly defined.
- Notes: This is not a problem since the JWSDL's WSDLReader is flexible
w.r.t the order of the source WSDL 1.1 document, and we output the WSDL
2.0
document in the proper order.
Definition of faults:
- In 1.1, faults are defined directly within operations, and the name of a
fault must be unique within the enclosing operation.
- In 2.0, faults are defined within interfaces, and referred to from
within
operations; fault names must be unique within the enclosing interface.
- Notes: Any fault name found to be ambiguous (when moved directly under
the interface) has the suffix "_n" appended to it, with n increasing from
1
until the name is unique. If more than 1 fault refer to the same element
type, the definitions are merged.
Imports:
- In 1.1, it is permitted to import documents that are from the same
targetNamespace as the importing document, as well as documents that are
not.
- In 2.0, import can only be used to import documents that are from a
different targetNamespace than the document doing the importing. The
include element can be used to import documents that are from the same
targetNamespace.
- Notes: If the imported document has the same targetNamespace as the
importing document, an include is generated; otherwise, an import is
generated.
Support for soapAction:
- In 1.1, there is a soapAction attribute defined on the extensibility
element <soap:operation>, which is a child of BindingOperation.
- In 2.0, there is a wsoap:action attribute defined directly on the
BindingOperation.
- Notes: During conversion, the value is copied directly from the
soapAction attribute to the wsoap:action attribute.
Thanks,
-Matt
Arthur Ryman
<ryman@ca.ibm.com To:
woden-dev@ws.apache.org
> cc:
woden-dev@ws.apache.org
Subject: Re: Woden & WSDL
1.1
03/17/2006 11:30
AM
Please respond to
woden-dev
Matthew,
This sounds like a great first step towards unifying WSDL 1.1 and WSDL
2.0.
We need to decide on the internal model that Axis2 will use. We could
either enhance WOM to support WSDL 2.0, or enhance Woden to support WSDL
1.1.
The way to enhance WSDL 2.0 to support WSDL 1.1 is via extensions. Would
you be able to define a WSDL 2.0 extension to support rpc/enc? I see that
as the major obstacle to adopting the Woden component model for Axis2
since
there are so many legacy rpc/enc services. WSDL 2.0 is highly extensible
so
this should be feasible. This is essentially a new binding. For
completeness, we need to support all combos of rpc and doc with encoding
and literal.
The other main mismatch is that a WSDL 2.0 <service> implements a single
<interface>. In WSDL 1.1, a service can contain endpoints ( <port>'s) that
implement arbitrary interfaces (<portType>'s). To map WSDL 1.1 to WSDL
2.0,
you'd have to split up a <wsdl11:service> into several <wsdl20:service>
elements. However, we should preserve the relation between these split up
services so we can generate the same WSDL 1.1 again. This could also be
handled with an extension.
By extensions I mean a new set of elements and attributes in a new
namespace, placed in appropriate positions, together with a specification
of their meaning and affect on the component model. See WSDL 2.0 Part 2
[1]
for examples.
You would then have to morph your code so that it constructed extended
WSDL
2.0 documents and we'd also need the extension handlers so they could add
the extensions to the Woden component model.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Matthew Duftler <du...@us.ibm.com>
To
03/17/2006 09:25 AM woden-dev@ws.apache.
org
cc
Please respond to
woden-dev@ws.apache.org Subject
Re: Woden & WSDL 1.1
Hi Guys,
I have some code that can help with a shorter-term solution for option 1.
In the course of comparing WSDL 2.0 with WSDL 1.1, I've written some Java
code that can convert a 1.1 document into a 2.0 document.
When I started this project, quite a while ago, I had intended to use
XSLT.
After working on it for a few days, I decided to abandon the XSLT effort,
and switch to a Java-based solution. The utility works by first reading
the
document into a JWSDL Definition. The advantages of this method over using
XSLT are:
- The dereferencing of WSDL elements is basically done already (I say
basically, because no real validation is being done.)
- The message pattern of each WSDL 1.1 operation (one-way,
request-response, solicit-response, notification) is determined by the
WSDLReader, not the conversion utility.
- Faster development time (and easier maintenance).
- It will be easier to modify this code to directly produce the new WSDL
2.0 model, if desired.
The code consists of 2 classes, with a total of about 1500 lines of code.
It presently is used as a command-line utility, but does have entry-points
that would only require minor modification to code-gen into
client-specified streams, instead of files. The reason it presently
produces files is because it attempts to walk the entire Definition graph
to convert all imported definitions into WSDL 2.0. This obviously requires
multiple output streams.
I can provide some more details if folks are interested. In short, its
only
major constraint is that it supports solely doc/lit WSDL 1.1 documents. If
it encounters a non- doc/lit 1.1 document, it throws an exception. There
is
a sort-term solution (gen <xsd:any> elements), and a long-term solution
(generate whatever MEP and associated stuff is appropriate), but I don't
really have the time to add this logic anymore.
I also wrote a bit of testing code that will attempt to convert entire
trees of WSDL 1.1 documents into WSDL 2.0, and then validate them. It
presently does only schema-validation. This could be easily changed to use
Woden to do the validation. I was using this code to ensure proper
coverage
of the 1.1 specification.
I would probably need a couple of days time to properly integrate it into
the codebase, and to add some comments.
At present, I am in limbo with regards to committing anyway. If I read the
link that was posted yesterday properly, my Apache id falls into both of
the following categories:
- I am a committer who has not signed a CLA.
- I have a signed CLA, but I am not a committer.
I'm not quite sure how both of these things can be true at the same time,
but I have signed a new ICLA and I faxed it to Apache yesterday.
Thanks,
-Matt Duftler
John Kaputin
<KAPUTIN@uk.ibm.c To:
woden-dev@ws.apache.org
om> cc:
Subject: Re: Woden & WSDL
1.1
03/16/2006 11:01
AM
Please respond to
woden-dev
Jim,
as Arthur mentions, WSDL 1.1 support in Woden is an ultimate objective of
the project.
There are actually two objectives:
1) converting a wsdl 1.1 document into the WSDL 2.0 component model.
2) converting a wsdl 1.1 document into a WSDL 1.1 object model (e.g. the
Definition object implemented in wsdl4j)
Option 1) will support applications that need a common wsdl model
regardless of the source document (1.1 or 2.0).
Option 2) will provide 'native' wsdl 1.1 support for applications that
currently require it, with a migration path to move to wsdl 2.0.
The current focus on WSDL 2.0 compliance and the longer term plan for wsdl
1.1 support in Woden is based on current priorities and available
resource.
Our developer resource to date (2 developers) have only been able to focus
on the highest priority item, WSDL 2.0 functionality and for the time
being
will continue to do so until the reference implementation is complete. If
Woden can attract more developers we may be able to expand our scope
sooner. Contributors can volunteer to work on particular items such as
WSDL 1.1 support if that is of interest to them.
regards,
John Kaputin
Arthur Ryman
<ryman@ca.ibm.com
> To
woden-dev@ws.apache.org
16/03/2006 14:25 cc
woden-dev@ws.apache.org
Subject
Please respond to Re: Woden & WSDL 1.1
woden-dev@ws.apac
he.org
Jim,
The initial goal of Woden 1.0 is to help get the WSDL 2.0 specification
out
of the CR stage and become a W3C Recommendation. We are therefore focusing
on the quality of the WSDL 2.0. We want to identify problems in the spec
before they become enshrined as part of the standard. So no, both WSDL 1.1
and WS-I are out of scope for the initial release. However, it is a longer
term goal to have a single implementation that handles WSDL 1.1 too and
that is extensible so that other validation rules, like WS-I, can be
plug-in.
If you need WSDL 1.1 and WS-I support, use WSDL4J at Apache and the WS-I
Tools Tools in WTP at Eclipse.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
"jim ma" <ma...@gmail.com>
To
03/16/2006 01:13 AM woden-dev@ws.apache.or
g
cc
Please respond to
woden-dev@ws.apache.org Subject
Woden & WSDL 1.1
Hi , all
Just tried woden and I have two qustions about it :
[1] Will Woden1.0 support parsing and validating WSDL 1.1 documents ?
[2] Does Woden intend to do the validation inculde ws-i basic profile
conformance ?
Thanks
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Woden & WSDL 1.1
Posted by Arthur Ryman <ry...@ca.ibm.com>.
Matt,
Axis2 needs to continue to support WSDL 1.1. Simply migrating all the old
WSDL 1.1 to WSDL 2.0 isn't a solution because the installed base of tools,
runtimes, etc. currently uses WSDL 1.1, including things like RPC/Enc that
are not part of the WSDL 2.0 Core spec.
We want to get a WSDL 2.0 implementation asap to help get the spec out of
CR status. The quickest way to do this is to integrate Woden into Axis2.
The Axis2 team wants a single object model. Currently they use WOM. We
believe Woden can replace WOM.
However, for Woden to replace WOM, it would need to support WSDL 1.1.
There is a big intersection between WSDL 1.1 and WSDL 2.0 so it is
feasible to serialize WSDL 1.1 documents from the Woden component model
(CM). However, there are feautres of WSDL 1.1 that were left out of the
WSDL 2.0 spec, e.g. RPC/Enc. WSDL 2.0 is highly extensible so it should be
possible to define WSDL 2.0 extensions to capture the missing features of
WSDL 1.1. This would effectively let you imbed WSDL 1.1 in WSDL 2.0.
To sum up, Woden CM could replace WOM and support both WSDL 2.0 and 1.1 if
we define a few extensions.
The conversion tool is still very interesting for migration and as a way
to generate WSDL 2.0 test cases.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Matthew Duftler <du...@us.ibm.com>
04/04/2006 11:18 AM
Please respond to
woden-dev@ws.apache.org
To
woden-dev@ws.apache.org
cc
Subject
Re: Woden & WSDL 1.1
Hi Art,
So you are basically saying for Axis to use the Woden Component Model as a
replacement for the WOM, Woden needs to be able to round-trip both WSDL
1.1
and 2.0 (and also do whatever 1.1 <-> 2.0 conversions are possible).
If (for certain cases, like RPC/ENC) Axis has to learn how to navigate
newly-defined 2.0 extensions, how is that different from just navigating
JWSDL for those cases?
I guess the thing for the Woden community to decide is whether this
converter code will fulfill requirements that others have (like simply
converting 1.1 to 2.0, without regard to roundtripping).
My view is that this converter code can go a long way towards helping
Woden
support WSDL 1.1 (even if this code is just used temporarily).
Thanks,
-Matt
Arthur Ryman
<ryman@ca.ibm.com To: woden-dev@ws.apache.org
> cc: woden-dev@ws.apache.org
Subject: Re: Woden & WSDL
1.1
04/01/2006 11:54
AM
Please respond to
woden-dev
Matt,
My suggestion is not for the converter. It's for using the WSDL 2.0
Component Model as a replacement for the WOM in Axis2. At present, there
are a lot of things in WSDL 1.1 that can't be expressed in WSDL 2.0 as you
have enumerated in your work on the converter. However, there is a huge
area of overlap so most of WSDL 1.1 can be expressed in terms of the
Component Model. To express the others, extensions are needed, e.g. for
rpc/encoded.
The goal is to use the Woden Component Model as the internal
representation
for WSDL in Axis2 and to be able to serialize it as both WSDL 2.0 or WSDL
1.1. Any component model instance could be serialized as WSDL 2.0 using
the
extensions. A subset of instances could also be serialized as WSDL 1.1.
This means that Axis2 can still support "legacy" WSDL 1.1 documents via
Woden. Otherwise, Axis2 would need 2 models.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Matthew Duftler <du...@us.ibm.com>
To
03/31/2006 04:37 PM woden-dev@ws.apache.
org
cc
Please respond to
woden-dev@ws.apache.org Subject
Re: Woden & WSDL 1.1
Hi Art,
Sorry for taking a while to respond to this; I'm playing a bit of email
catchup.
I'm not quite sure I see why adding the ability to convert 1.1 documents
into 2.0 requires new extensions (I haven't really thought much about
supporting rpc-type WSDL 1.1 docs, though).
>Further to me previous note, we'd need WSDL 2.0 extensions to capture
most
of these differences.
Why does Woden need to capture most of these differences? As long as the
conversion/mapping from 1.1 to 2.0 is reasonable and public, why would you
need to maintain the original representation? Actually, if you are going
to
define extensions to represent all the original 1.1 semantics, why
wouldn't
you just wrap the entire original 1.1 syntax, and use that as a 2.0
extension? Either way, you need to navigate an additional representation,
no?
Thanks,
-Matt
Arthur Ryman
<ryman@ca.ibm.com To:
woden-dev@ws.apache.org
> cc:
woden-dev@ws.apache.org
Subject: Re: Woden & WSDL
1.1
03/17/2006 05:34
PM
Please respond to
woden-dev
Matt,
Nice list. I think the W3C once started a document that outlined all the
differences. I don't rememeber what happened to it, but I think it would
be
a very useful thing to have.
Further to me previous note, we'd need WSDL 2.0 extensions to capture most
of these differences.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Matthew Duftler <du...@us.ibm.com>
To
03/17/2006 04:45 PM woden-dev@ws.apache.
org
cc
Please respond to woden-dev@ws.apache.
woden-dev@ws.apache.org org
Subject
Re: Woden & WSDL 1.1
Hi Arthur,
>The other main mismatch is that a WSDL 2.0 <service> implements a single
<interface>. In WSDL 1.1, a service can contain endpoints ( <port>'s) that
im>plement arbitrary interfaces (<portType>'s). To map WSDL 1.1 to WSDL
2.0, you'd have to split up a <wsdl11:service> into several
<wsdl20:service> >elements. However, we should preserve the relation
between these split up services so we can generate the same WSDL 1.1
again.
This could also be >handled with an extension.
In the course of creating the conversion code I came across quite a few
constructs that are handled differently in 1.1 vs 2.0. I created a short
list with some notes of how I handled the issues:
Definition of service components:
- In 1.1, <service>s can have multiple <port>s, with each <port> bound to
a
different <portType>.
- In 2.0, <service>s are bound to one <interface>.
- Notes: If a service is encountered that has ports bound to more than one
portType, a service is generated for each referenced portType. Each newly
generated service has the suffix "_n" appended to its name, with n
increasing from 1 until the name is unique.
Overloading of operation names:
- In 1.1, <operation> names are permitted to be overloaded. When referring
to overloaded <operation>s from <binding>s, <operation>s are uniquely
identified by using the names of the <input> and <output> elements in
addition to the name of the <operation>.
- In 2.0, <operation> names must be unique within an <interface>.
- Notes: Any operation name found to be overloaded has the suffix "_n"
appended to it, with n increasing from 1 until the name is unique.
targetNamespace requirements:
- In 1.1, the targetNamespace attribute of <definition> is optional; if it
is not specified, all references to items defined within the document must
be done without prefixes, and the default namespace must be set to "".
Also, if no targetNamespace is specified, no top-level items defined
within
the document can be referred to from other WSDL documents.
- In 2.0, the targetNamespace attribute of <description> is required.
- Notes: There is a -targetNS command-line argument that allows the user
to
specify the targetNamespace to be used. If the source 1.1 document does
not
specify a targetNamespace, this argument is required; if the source 1.1
document does specify a targetNamespace, the argument serves as an
optional
way to override the specified targetNamespace. The targetNamespace
replacement will propagate via a generated include, but not via a
generated
import.
Ordering of top-level elements:
- In 1.1, the children of <definition> may appear in any order (even
though
the schema says otherwise).
- In 2.0, the order is strictly defined.
- Notes: This is not a problem since the JWSDL's WSDLReader is flexible
w.r.t the order of the source WSDL 1.1 document, and we output the WSDL
2.0
document in the proper order.
Definition of faults:
- In 1.1, faults are defined directly within operations, and the name of a
fault must be unique within the enclosing operation.
- In 2.0, faults are defined within interfaces, and referred to from
within
operations; fault names must be unique within the enclosing interface.
- Notes: Any fault name found to be ambiguous (when moved directly under
the interface) has the suffix "_n" appended to it, with n increasing from
1
until the name is unique. If more than 1 fault refer to the same element
type, the definitions are merged.
Imports:
- In 1.1, it is permitted to import documents that are from the same
targetNamespace as the importing document, as well as documents that are
not.
- In 2.0, import can only be used to import documents that are from a
different targetNamespace than the document doing the importing. The
include element can be used to import documents that are from the same
targetNamespace.
- Notes: If the imported document has the same targetNamespace as the
importing document, an include is generated; otherwise, an import is
generated.
Support for soapAction:
- In 1.1, there is a soapAction attribute defined on the extensibility
element <soap:operation>, which is a child of BindingOperation.
- In 2.0, there is a wsoap:action attribute defined directly on the
BindingOperation.
- Notes: During conversion, the value is copied directly from the
soapAction attribute to the wsoap:action attribute.
Thanks,
-Matt
Arthur Ryman
<ryman@ca.ibm.com To:
woden-dev@ws.apache.org
> cc:
woden-dev@ws.apache.org
Subject: Re: Woden & WSDL
1.1
03/17/2006 11:30
AM
Please respond to
woden-dev
Matthew,
This sounds like a great first step towards unifying WSDL 1.1 and WSDL
2.0.
We need to decide on the internal model that Axis2 will use. We could
either enhance WOM to support WSDL 2.0, or enhance Woden to support WSDL
1.1.
The way to enhance WSDL 2.0 to support WSDL 1.1 is via extensions. Would
you be able to define a WSDL 2.0 extension to support rpc/enc? I see that
as the major obstacle to adopting the Woden component model for Axis2
since
there are so many legacy rpc/enc services. WSDL 2.0 is highly extensible
so
this should be feasible. This is essentially a new binding. For
completeness, we need to support all combos of rpc and doc with encoding
and literal.
The other main mismatch is that a WSDL 2.0 <service> implements a single
<interface>. In WSDL 1.1, a service can contain endpoints ( <port>'s) that
implement arbitrary interfaces (<portType>'s). To map WSDL 1.1 to WSDL
2.0,
you'd have to split up a <wsdl11:service> into several <wsdl20:service>
elements. However, we should preserve the relation between these split up
services so we can generate the same WSDL 1.1 again. This could also be
handled with an extension.
By extensions I mean a new set of elements and attributes in a new
namespace, placed in appropriate positions, together with a specification
of their meaning and affect on the component model. See WSDL 2.0 Part 2
[1]
for examples.
You would then have to morph your code so that it constructed extended
WSDL
2.0 documents and we'd also need the extension handlers so they could add
the extensions to the Woden component model.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Matthew Duftler <du...@us.ibm.com>
To
03/17/2006 09:25 AM woden-dev@ws.apache.
org
cc
Please respond to
woden-dev@ws.apache.org Subject
Re: Woden & WSDL 1.1
Hi Guys,
I have some code that can help with a shorter-term solution for option 1.
In the course of comparing WSDL 2.0 with WSDL 1.1, I've written some Java
code that can convert a 1.1 document into a 2.0 document.
When I started this project, quite a while ago, I had intended to use
XSLT.
After working on it for a few days, I decided to abandon the XSLT effort,
and switch to a Java-based solution. The utility works by first reading
the
document into a JWSDL Definition. The advantages of this method over using
XSLT are:
- The dereferencing of WSDL elements is basically done already (I say
basically, because no real validation is being done.)
- The message pattern of each WSDL 1.1 operation (one-way,
request-response, solicit-response, notification) is determined by the
WSDLReader, not the conversion utility.
- Faster development time (and easier maintenance).
- It will be easier to modify this code to directly produce the new WSDL
2.0 model, if desired.
The code consists of 2 classes, with a total of about 1500 lines of code.
It presently is used as a command-line utility, but does have entry-points
that would only require minor modification to code-gen into
client-specified streams, instead of files. The reason it presently
produces files is because it attempts to walk the entire Definition graph
to convert all imported definitions into WSDL 2.0. This obviously requires
multiple output streams.
I can provide some more details if folks are interested. In short, its
only
major constraint is that it supports solely doc/lit WSDL 1.1 documents. If
it encounters a non- doc/lit 1.1 document, it throws an exception. There
is
a sort-term solution (gen <xsd:any> elements), and a long-term solution
(generate whatever MEP and associated stuff is appropriate), but I don't
really have the time to add this logic anymore.
I also wrote a bit of testing code that will attempt to convert entire
trees of WSDL 1.1 documents into WSDL 2.0, and then validate them. It
presently does only schema-validation. This could be easily changed to use
Woden to do the validation. I was using this code to ensure proper
coverage
of the 1.1 specification.
I would probably need a couple of days time to properly integrate it into
the codebase, and to add some comments.
At present, I am in limbo with regards to committing anyway. If I read the
link that was posted yesterday properly, my Apache id falls into both of
the following categories:
- I am a committer who has not signed a CLA.
- I have a signed CLA, but I am not a committer.
I'm not quite sure how both of these things can be true at the same time,
but I have signed a new ICLA and I faxed it to Apache yesterday.
Thanks,
-Matt Duftler
John Kaputin
<KAPUTIN@uk.ibm.c To:
woden-dev@ws.apache.org
om> cc:
Subject: Re: Woden & WSDL
1.1
03/16/2006 11:01
AM
Please respond to
woden-dev
Jim,
as Arthur mentions, WSDL 1.1 support in Woden is an ultimate objective of
the project.
There are actually two objectives:
1) converting a wsdl 1.1 document into the WSDL 2.0 component model.
2) converting a wsdl 1.1 document into a WSDL 1.1 object model (e.g. the
Definition object implemented in wsdl4j)
Option 1) will support applications that need a common wsdl model
regardless of the source document (1.1 or 2.0).
Option 2) will provide 'native' wsdl 1.1 support for applications that
currently require it, with a migration path to move to wsdl 2.0.
The current focus on WSDL 2.0 compliance and the longer term plan for wsdl
1.1 support in Woden is based on current priorities and available
resource.
Our developer resource to date (2 developers) have only been able to focus
on the highest priority item, WSDL 2.0 functionality and for the time
being
will continue to do so until the reference implementation is complete. If
Woden can attract more developers we may be able to expand our scope
sooner. Contributors can volunteer to work on particular items such as
WSDL 1.1 support if that is of interest to them.
regards,
John Kaputin
Arthur Ryman
<ryman@ca.ibm.com
> To
woden-dev@ws.apache.org
16/03/2006 14:25 cc
woden-dev@ws.apache.org
Subject
Please respond to Re: Woden & WSDL 1.1
woden-dev@ws.apac
he.org
Jim,
The initial goal of Woden 1.0 is to help get the WSDL 2.0 specification
out
of the CR stage and become a W3C Recommendation. We are therefore focusing
on the quality of the WSDL 2.0. We want to identify problems in the spec
before they become enshrined as part of the standard. So no, both WSDL 1.1
and WS-I are out of scope for the initial release. However, it is a longer
term goal to have a single implementation that handles WSDL 1.1 too and
that is extensible so that other validation rules, like WS-I, can be
plug-in.
If you need WSDL 1.1 and WS-I support, use WSDL4J at Apache and the WS-I
Tools Tools in WTP at Eclipse.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
"jim ma" <ma...@gmail.com>
To
03/16/2006 01:13 AM woden-dev@ws.apache.or
g
cc
Please respond to
woden-dev@ws.apache.org Subject
Woden & WSDL 1.1
Hi , all
Just tried woden and I have two qustions about it :
[1] Will Woden1.0 support parsing and validating WSDL 1.1 documents ?
[2] Does Woden intend to do the validation inculde ws-i basic profile
conformance ?
Thanks
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Woden & WSDL 1.1
Posted by Matthew Duftler <du...@us.ibm.com>.
Hi Art,
So you are basically saying for Axis to use the Woden Component Model as a
replacement for the WOM, Woden needs to be able to round-trip both WSDL 1.1
and 2.0 (and also do whatever 1.1 <-> 2.0 conversions are possible).
If (for certain cases, like RPC/ENC) Axis has to learn how to navigate
newly-defined 2.0 extensions, how is that different from just navigating
JWSDL for those cases?
I guess the thing for the Woden community to decide is whether this
converter code will fulfill requirements that others have (like simply
converting 1.1 to 2.0, without regard to roundtripping).
My view is that this converter code can go a long way towards helping Woden
support WSDL 1.1 (even if this code is just used temporarily).
Thanks,
-Matt
Arthur Ryman
<ryman@ca.ibm.com To: woden-dev@ws.apache.org
> cc: woden-dev@ws.apache.org
Subject: Re: Woden & WSDL 1.1
04/01/2006 11:54
AM
Please respond to
woden-dev
Matt,
My suggestion is not for the converter. It's for using the WSDL 2.0
Component Model as a replacement for the WOM in Axis2. At present, there
are a lot of things in WSDL 1.1 that can't be expressed in WSDL 2.0 as you
have enumerated in your work on the converter. However, there is a huge
area of overlap so most of WSDL 1.1 can be expressed in terms of the
Component Model. To express the others, extensions are needed, e.g. for
rpc/encoded.
The goal is to use the Woden Component Model as the internal representation
for WSDL in Axis2 and to be able to serialize it as both WSDL 2.0 or WSDL
1.1. Any component model instance could be serialized as WSDL 2.0 using the
extensions. A subset of instances could also be serialized as WSDL 1.1.
This means that Axis2 can still support "legacy" WSDL 1.1 documents via
Woden. Otherwise, Axis2 would need 2 models.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Matthew Duftler <du...@us.ibm.com>
To
03/31/2006 04:37 PM woden-dev@ws.apache.
org
cc
Please respond to
woden-dev@ws.apache.org Subject
Re: Woden & WSDL 1.1
Hi Art,
Sorry for taking a while to respond to this; I'm playing a bit of email
catchup.
I'm not quite sure I see why adding the ability to convert 1.1 documents
into 2.0 requires new extensions (I haven't really thought much about
supporting rpc-type WSDL 1.1 docs, though).
>Further to me previous note, we'd need WSDL 2.0 extensions to capture most
of these differences.
Why does Woden need to capture most of these differences? As long as the
conversion/mapping from 1.1 to 2.0 is reasonable and public, why would you
need to maintain the original representation? Actually, if you are going to
define extensions to represent all the original 1.1 semantics, why wouldn't
you just wrap the entire original 1.1 syntax, and use that as a 2.0
extension? Either way, you need to navigate an additional representation,
no?
Thanks,
-Matt
Arthur Ryman
<ryman@ca.ibm.com To:
woden-dev@ws.apache.org
> cc:
woden-dev@ws.apache.org
Subject: Re: Woden & WSDL
1.1
03/17/2006 05:34
PM
Please respond to
woden-dev
Matt,
Nice list. I think the W3C once started a document that outlined all the
differences. I don't rememeber what happened to it, but I think it would be
a very useful thing to have.
Further to me previous note, we'd need WSDL 2.0 extensions to capture most
of these differences.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Matthew Duftler <du...@us.ibm.com>
To
03/17/2006 04:45 PM woden-dev@ws.apache.
org
cc
Please respond to woden-dev@ws.apache.
woden-dev@ws.apache.org org
Subject
Re: Woden & WSDL 1.1
Hi Arthur,
>The other main mismatch is that a WSDL 2.0 <service> implements a single
<interface>. In WSDL 1.1, a service can contain endpoints ( <port>'s) that
im>plement arbitrary interfaces (<portType>'s). To map WSDL 1.1 to WSDL
2.0, you'd have to split up a <wsdl11:service> into several
<wsdl20:service> >elements. However, we should preserve the relation
between these split up services so we can generate the same WSDL 1.1 again.
This could also be >handled with an extension.
In the course of creating the conversion code I came across quite a few
constructs that are handled differently in 1.1 vs 2.0. I created a short
list with some notes of how I handled the issues:
Definition of service components:
- In 1.1, <service>s can have multiple <port>s, with each <port> bound to a
different <portType>.
- In 2.0, <service>s are bound to one <interface>.
- Notes: If a service is encountered that has ports bound to more than one
portType, a service is generated for each referenced portType. Each newly
generated service has the suffix "_n" appended to its name, with n
increasing from 1 until the name is unique.
Overloading of operation names:
- In 1.1, <operation> names are permitted to be overloaded. When referring
to overloaded <operation>s from <binding>s, <operation>s are uniquely
identified by using the names of the <input> and <output> elements in
addition to the name of the <operation>.
- In 2.0, <operation> names must be unique within an <interface>.
- Notes: Any operation name found to be overloaded has the suffix "_n"
appended to it, with n increasing from 1 until the name is unique.
targetNamespace requirements:
- In 1.1, the targetNamespace attribute of <definition> is optional; if it
is not specified, all references to items defined within the document must
be done without prefixes, and the default namespace must be set to "".
Also, if no targetNamespace is specified, no top-level items defined within
the document can be referred to from other WSDL documents.
- In 2.0, the targetNamespace attribute of <description> is required.
- Notes: There is a -targetNS command-line argument that allows the user to
specify the targetNamespace to be used. If the source 1.1 document does not
specify a targetNamespace, this argument is required; if the source 1.1
document does specify a targetNamespace, the argument serves as an optional
way to override the specified targetNamespace. The targetNamespace
replacement will propagate via a generated include, but not via a generated
import.
Ordering of top-level elements:
- In 1.1, the children of <definition> may appear in any order (even though
the schema says otherwise).
- In 2.0, the order is strictly defined.
- Notes: This is not a problem since the JWSDL's WSDLReader is flexible
w.r.t the order of the source WSDL 1.1 document, and we output the WSDL 2.0
document in the proper order.
Definition of faults:
- In 1.1, faults are defined directly within operations, and the name of a
fault must be unique within the enclosing operation.
- In 2.0, faults are defined within interfaces, and referred to from within
operations; fault names must be unique within the enclosing interface.
- Notes: Any fault name found to be ambiguous (when moved directly under
the interface) has the suffix "_n" appended to it, with n increasing from 1
until the name is unique. If more than 1 fault refer to the same element
type, the definitions are merged.
Imports:
- In 1.1, it is permitted to import documents that are from the same
targetNamespace as the importing document, as well as documents that are
not.
- In 2.0, import can only be used to import documents that are from a
different targetNamespace than the document doing the importing. The
include element can be used to import documents that are from the same
targetNamespace.
- Notes: If the imported document has the same targetNamespace as the
importing document, an include is generated; otherwise, an import is
generated.
Support for soapAction:
- In 1.1, there is a soapAction attribute defined on the extensibility
element <soap:operation>, which is a child of BindingOperation.
- In 2.0, there is a wsoap:action attribute defined directly on the
BindingOperation.
- Notes: During conversion, the value is copied directly from the
soapAction attribute to the wsoap:action attribute.
Thanks,
-Matt
Arthur Ryman
<ryman@ca.ibm.com To:
woden-dev@ws.apache.org
> cc:
woden-dev@ws.apache.org
Subject: Re: Woden & WSDL
1.1
03/17/2006 11:30
AM
Please respond to
woden-dev
Matthew,
This sounds like a great first step towards unifying WSDL 1.1 and WSDL 2.0.
We need to decide on the internal model that Axis2 will use. We could
either enhance WOM to support WSDL 2.0, or enhance Woden to support WSDL
1.1.
The way to enhance WSDL 2.0 to support WSDL 1.1 is via extensions. Would
you be able to define a WSDL 2.0 extension to support rpc/enc? I see that
as the major obstacle to adopting the Woden component model for Axis2 since
there are so many legacy rpc/enc services. WSDL 2.0 is highly extensible so
this should be feasible. This is essentially a new binding. For
completeness, we need to support all combos of rpc and doc with encoding
and literal.
The other main mismatch is that a WSDL 2.0 <service> implements a single
<interface>. In WSDL 1.1, a service can contain endpoints ( <port>'s) that
implement arbitrary interfaces (<portType>'s). To map WSDL 1.1 to WSDL 2.0,
you'd have to split up a <wsdl11:service> into several <wsdl20:service>
elements. However, we should preserve the relation between these split up
services so we can generate the same WSDL 1.1 again. This could also be
handled with an extension.
By extensions I mean a new set of elements and attributes in a new
namespace, placed in appropriate positions, together with a specification
of their meaning and affect on the component model. See WSDL 2.0 Part 2 [1]
for examples.
You would then have to morph your code so that it constructed extended WSDL
2.0 documents and we'd also need the extension handlers so they could add
the extensions to the Woden component model.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
Matthew Duftler <du...@us.ibm.com>
To
03/17/2006 09:25 AM woden-dev@ws.apache.
org
cc
Please respond to
woden-dev@ws.apache.org Subject
Re: Woden & WSDL 1.1
Hi Guys,
I have some code that can help with a shorter-term solution for option 1.
In the course of comparing WSDL 2.0 with WSDL 1.1, I've written some Java
code that can convert a 1.1 document into a 2.0 document.
When I started this project, quite a while ago, I had intended to use XSLT.
After working on it for a few days, I decided to abandon the XSLT effort,
and switch to a Java-based solution. The utility works by first reading the
document into a JWSDL Definition. The advantages of this method over using
XSLT are:
- The dereferencing of WSDL elements is basically done already (I say
basically, because no real validation is being done.)
- The message pattern of each WSDL 1.1 operation (one-way,
request-response, solicit-response, notification) is determined by the
WSDLReader, not the conversion utility.
- Faster development time (and easier maintenance).
- It will be easier to modify this code to directly produce the new WSDL
2.0 model, if desired.
The code consists of 2 classes, with a total of about 1500 lines of code.
It presently is used as a command-line utility, but does have entry-points
that would only require minor modification to code-gen into
client-specified streams, instead of files. The reason it presently
produces files is because it attempts to walk the entire Definition graph
to convert all imported definitions into WSDL 2.0. This obviously requires
multiple output streams.
I can provide some more details if folks are interested. In short, its only
major constraint is that it supports solely doc/lit WSDL 1.1 documents. If
it encounters a non- doc/lit 1.1 document, it throws an exception. There is
a sort-term solution (gen <xsd:any> elements), and a long-term solution
(generate whatever MEP and associated stuff is appropriate), but I don't
really have the time to add this logic anymore.
I also wrote a bit of testing code that will attempt to convert entire
trees of WSDL 1.1 documents into WSDL 2.0, and then validate them. It
presently does only schema-validation. This could be easily changed to use
Woden to do the validation. I was using this code to ensure proper coverage
of the 1.1 specification.
I would probably need a couple of days time to properly integrate it into
the codebase, and to add some comments.
At present, I am in limbo with regards to committing anyway. If I read the
link that was posted yesterday properly, my Apache id falls into both of
the following categories:
- I am a committer who has not signed a CLA.
- I have a signed CLA, but I am not a committer.
I'm not quite sure how both of these things can be true at the same time,
but I have signed a new ICLA and I faxed it to Apache yesterday.
Thanks,
-Matt Duftler
John Kaputin
<KAPUTIN@uk.ibm.c To:
woden-dev@ws.apache.org
om> cc:
Subject: Re: Woden & WSDL
1.1
03/16/2006 11:01
AM
Please respond to
woden-dev
Jim,
as Arthur mentions, WSDL 1.1 support in Woden is an ultimate objective of
the project.
There are actually two objectives:
1) converting a wsdl 1.1 document into the WSDL 2.0 component model.
2) converting a wsdl 1.1 document into a WSDL 1.1 object model (e.g. the
Definition object implemented in wsdl4j)
Option 1) will support applications that need a common wsdl model
regardless of the source document (1.1 or 2.0).
Option 2) will provide 'native' wsdl 1.1 support for applications that
currently require it, with a migration path to move to wsdl 2.0.
The current focus on WSDL 2.0 compliance and the longer term plan for wsdl
1.1 support in Woden is based on current priorities and available resource.
Our developer resource to date (2 developers) have only been able to focus
on the highest priority item, WSDL 2.0 functionality and for the time being
will continue to do so until the reference implementation is complete. If
Woden can attract more developers we may be able to expand our scope
sooner. Contributors can volunteer to work on particular items such as
WSDL 1.1 support if that is of interest to them.
regards,
John Kaputin
Arthur Ryman
<ryman@ca.ibm.com
> To
woden-dev@ws.apache.org
16/03/2006 14:25 cc
woden-dev@ws.apache.org
Subject
Please respond to Re: Woden & WSDL 1.1
woden-dev@ws.apac
he.org
Jim,
The initial goal of Woden 1.0 is to help get the WSDL 2.0 specification out
of the CR stage and become a W3C Recommendation. We are therefore focusing
on the quality of the WSDL 2.0. We want to identify problems in the spec
before they become enshrined as part of the standard. So no, both WSDL 1.1
and WS-I are out of scope for the initial release. However, it is a longer
term goal to have a single implementation that handles WSDL 1.1 too and
that is extensible so that other validation rules, like WS-I, can be
plug-in.
If you need WSDL 1.1 and WS-I support, use WSDL4J at Apache and the WS-I
Tools Tools in WTP at Eclipse.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
"jim ma" <ma...@gmail.com>
To
03/16/2006 01:13 AM woden-dev@ws.apache.or
g
cc
Please respond to
woden-dev@ws.apache.org Subject
Woden & WSDL 1.1
Hi , all
Just tried woden and I have two qustions about it :
[1] Will Woden1.0 support parsing and validating WSDL 1.1 documents ?
[2] Does Woden intend to do the validation inculde ws-i basic profile
conformance ?
Thanks
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org