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
<[EMAIL PROTECTED] To:
[email protected]
> cc:
[email protected]
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: [EMAIL PROTECTED]
Matthew Duftler <[EMAIL PROTECTED]>
To
03/17/2006 09:25 AM [EMAIL PROTECTED]
org
cc
Please respond to
[email protected] 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
<[EMAIL PROTECTED] To:
[email protected]
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
<[EMAIL PROTECTED]
> To
[email protected]
16/03/2006 14:25 cc
[email protected]
Subject
Please respond to Re: Woden & WSDL 1.1
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
"jim ma" <[EMAIL PROTECTED]>
To
03/16/2006 01:13 AM [EMAIL PROTECTED]
g
cc
Please respond to
[email protected] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
