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 John Kaputin <KA...@uk.ibm.com> on 2005/11/03 22:56:06 UTC
Design change for WSDL Description implementation
I have just committed change r330632 so that now the Description and
DescriptionElement interfaces are implemented by a single class,
DescriptionImpl. Details of the design change, the rationale and a UML
class diagram are in the attached PDF. Comments welcome.
(See attached file: Design for WSDL Description.pdf)
BTW, I have various fragments of design in Word and UML that I still need
to collate into some design documentation on the website or wiki.
John Kaputin
Re: Status and help proposal
Posted by Guillaume Nodet <gn...@codehaus.org>.
Thanks a lot John.
My main need is to be able to:
* load a wsdl from a Document
* locate the service for a specified qname
* find the associated binding type
* find the associated interface name
So i'll keep a look and give you feedback as soon as M2 is out, or svn
head can fullfill some part of it.
Cheers,
Guillaume Nodet
John Kaputin wrote:
>Hi Guillaume,
>other readWSDL methods will be added to the WSDLReader interface, probably
>similar to the readWSDL methods in the WSDL 1.1 processor, WSDL4J. This
>includes a readWSDL method that takes a DOM Document. I have net yet
>focussed on the other readWSDL methods required, but I can add easily add
>the Document argument readWSDL method.
>
>We have just revised the milestone plan and will update the web page
>shortly. M2 is now due Dec 2nd. It still delivers Binding components,
>including support for extensibility because this is required for the
>mandatory extensions (SOAP and HTTP bindings). M2 will include the SOAP
>extensions. HTTP bindings will follow in M3 due Jan 20. M3 is largely about
>validation, but it does currently include the Service component. However,
>there is not much to Service so I can do it sooner rather than later.
>
>I will aim to meet your first objective (reading a wsdl2 description from a
>DOM document) by M2 in 3 weeks time - including the Service component. The
>wsdl 1.1. conversion will take longer and we have a couple of people lined
>up to work on this, but let us know if you have something to contribute.
>
>The design and implementation of Woden are maturing rapidly and should be
>stable enough by M2 for others to use as a base to build upon. I'm
>currently working on the Binding components and would prefer to complete
>that myself to maintain consistency. This should ensure a common baseline
>for reviewing the design and implementation. But there's plenty more to do
>beyond Binding and Service, so M2 would probably be a good point to get
>involved with functional development if you're interested.
>
>In the meantime we could really use some help with testing what we have.
>Perhaps you could try using it against your own WSDL documents. Or create
>WSDL testcases based on the W3C WSDL 2.0 spec (and ideally contribute any
>WSDL to the www-ws-desc@w3.org mailing list so the W3C working group can
>add it to their WSDL 2.0 test suite). And let us know if the Woden API
>meets your functional and usability needs - contributing suggestions or
>code as you like. To get the Binding and Service functionality as I
>complete it, you should use the latest code from the Subversion repository.
>
>Other Woden objectives beyond the core WSDL 2.0 parsing are:
>* WSDL 1.1 to 2.0 conversion
>* API support for the wsdl 1.1. model (e.g. via the JWSDL API from JSR110)
>* WSDLWriter functionality for modifying or programmatically creating WSDL
>documents.
>* support for other XML parsers (e.g. JSR173 StAX)
>* support for other type systems besides XML Schema.
>
>regards,
>John Kaputin
>
>
>
>
> Guillaume Nodet
> <gnt@codehaus.org
> > To
> woden-dev@ws.apache.org
> 08/11/2005 10:46 cc
>
> Subject
> Please respond to Status and help proposal
> woden-dev
>
>
>
>
>
>
>
>
>
>Hi everybody.
>
>I'm working on servicemix (http://servicemix.org), a JBI container.
>The JBI specs mandates the use of wsdl 2.0 and we currently handle only
>wsdl 1.
>So i'm looking for something to read (maybe write) wsdl 2.
>
>I need the following features:
> * read wsdl 2 documents from an existing dom Document
> * read wsdl 1 would be very handy, else i'll have to have two
>libraries and check before what wsdl version it is
>
> From what i understand, and what i saw, the api does not have any mean
>to read a wsdl from an existing doc.
>It should be very easy to add, as the parser already uses dom (just
>missing in the api, i think). Having lots of ways
>to read wsdls is a real need, imho (maybe reading from a jaxp source
>could handle most of the cases).
>
>The parsing currently does not read the full wsdl (binding among other
>things is not parsed yet).
>I do not need complete validation aso, but i need to retrieve at least
>basic informations.
>
>I've seen on the mailing list that someone will work on the wsdl 1.1 ->
>2.0 conversion.
>
> From the milestone plan, it seems that you are focusing on parsing
>binding first (M2), then services (M3).
>As for me, i'd prefer to be able to parse the whole wsdl, even if some
>data is not handled (extensibility elements
>for example), but ...
>
>Thus, i'm willingfull to offer my help so that i could use woden in
>servicemix.
>
>Cheers,
>Guillaume Nodet
>
>
>---------------------------------------------------------------------
>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: Status and help proposal
Posted by John Kaputin <KA...@uk.ibm.com>.
Hi Guillaume,
other readWSDL methods will be added to the WSDLReader interface, probably
similar to the readWSDL methods in the WSDL 1.1 processor, WSDL4J. This
includes a readWSDL method that takes a DOM Document. I have net yet
focussed on the other readWSDL methods required, but I can add easily add
the Document argument readWSDL method.
We have just revised the milestone plan and will update the web page
shortly. M2 is now due Dec 2nd. It still delivers Binding components,
including support for extensibility because this is required for the
mandatory extensions (SOAP and HTTP bindings). M2 will include the SOAP
extensions. HTTP bindings will follow in M3 due Jan 20. M3 is largely about
validation, but it does currently include the Service component. However,
there is not much to Service so I can do it sooner rather than later.
I will aim to meet your first objective (reading a wsdl2 description from a
DOM document) by M2 in 3 weeks time - including the Service component. The
wsdl 1.1. conversion will take longer and we have a couple of people lined
up to work on this, but let us know if you have something to contribute.
The design and implementation of Woden are maturing rapidly and should be
stable enough by M2 for others to use as a base to build upon. I'm
currently working on the Binding components and would prefer to complete
that myself to maintain consistency. This should ensure a common baseline
for reviewing the design and implementation. But there's plenty more to do
beyond Binding and Service, so M2 would probably be a good point to get
involved with functional development if you're interested.
In the meantime we could really use some help with testing what we have.
Perhaps you could try using it against your own WSDL documents. Or create
WSDL testcases based on the W3C WSDL 2.0 spec (and ideally contribute any
WSDL to the www-ws-desc@w3.org mailing list so the W3C working group can
add it to their WSDL 2.0 test suite). And let us know if the Woden API
meets your functional and usability needs - contributing suggestions or
code as you like. To get the Binding and Service functionality as I
complete it, you should use the latest code from the Subversion repository.
Other Woden objectives beyond the core WSDL 2.0 parsing are:
* WSDL 1.1 to 2.0 conversion
* API support for the wsdl 1.1. model (e.g. via the JWSDL API from JSR110)
* WSDLWriter functionality for modifying or programmatically creating WSDL
documents.
* support for other XML parsers (e.g. JSR173 StAX)
* support for other type systems besides XML Schema.
regards,
John Kaputin
Guillaume Nodet
<gnt@codehaus.org
> To
woden-dev@ws.apache.org
08/11/2005 10:46 cc
Subject
Please respond to Status and help proposal
woden-dev
Hi everybody.
I'm working on servicemix (http://servicemix.org), a JBI container.
The JBI specs mandates the use of wsdl 2.0 and we currently handle only
wsdl 1.
So i'm looking for something to read (maybe write) wsdl 2.
I need the following features:
* read wsdl 2 documents from an existing dom Document
* read wsdl 1 would be very handy, else i'll have to have two
libraries and check before what wsdl version it is
From what i understand, and what i saw, the api does not have any mean
to read a wsdl from an existing doc.
It should be very easy to add, as the parser already uses dom (just
missing in the api, i think). Having lots of ways
to read wsdls is a real need, imho (maybe reading from a jaxp source
could handle most of the cases).
The parsing currently does not read the full wsdl (binding among other
things is not parsed yet).
I do not need complete validation aso, but i need to retrieve at least
basic informations.
I've seen on the mailing list that someone will work on the wsdl 1.1 ->
2.0 conversion.
From the milestone plan, it seems that you are focusing on parsing
binding first (M2), then services (M3).
As for me, i'd prefer to be able to parse the whole wsdl, even if some
data is not handled (extensibility elements
for example), but ...
Thus, i'm willingfull to offer my help so that i could use woden in
servicemix.
Cheers,
Guillaume Nodet
---------------------------------------------------------------------
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
Status and help proposal
Posted by Guillaume Nodet <gn...@codehaus.org>.
Hi everybody.
I'm working on servicemix (http://servicemix.org), a JBI container.
The JBI specs mandates the use of wsdl 2.0 and we currently handle only
wsdl 1.
So i'm looking for something to read (maybe write) wsdl 2.
I need the following features:
* read wsdl 2 documents from an existing dom Document
* read wsdl 1 would be very handy, else i'll have to have two
libraries and check before what wsdl version it is
From what i understand, and what i saw, the api does not have any mean
to read a wsdl from an existing doc.
It should be very easy to add, as the parser already uses dom (just
missing in the api, i think). Having lots of ways
to read wsdls is a real need, imho (maybe reading from a jaxp source
could handle most of the cases).
The parsing currently does not read the full wsdl (binding among other
things is not parsed yet).
I do not need complete validation aso, but i need to retrieve at least
basic informations.
I've seen on the mailing list that someone will work on the wsdl 1.1 ->
2.0 conversion.
From the milestone plan, it seems that you are focusing on parsing
binding first (M2), then services (M3).
As for me, i'd prefer to be able to parse the whole wsdl, even if some
data is not handled (extensibility elements
for example), but ...
Thus, i'm willingfull to offer my help so that i could use woden in
servicemix.
Cheers,
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Design change for WSDL Description implementation
Posted by John Kaputin <KA...@uk.ibm.com>.
Arthur,
In the case where a Description component represents multiple <description>
elements consisting of a 'root' <description> element and one or more
levels of imported or included <description>s, the properties of that
Description component (Interfaces, Bindings, Services, etc) are drawn from
all of those <description> elements, not just the root element. The
Description component is created by calling toComponent() on the
DescriptionElement representing the root <description> element and the
behaviour is to navigate down the tree of DescriptionElement and
ImportElement or IncludeElement objects to populate the properties of the
Description component object. Note that WSDL <import> and <include> are
not yet implemented in Woden, but this is how I expect it to work.
The toElement() method of the Description component will return a reference
to the DescriptionElement representing the root <description> element from
which the Description component was created. This DescriptionElement can be
used to provide the same information as the Description component's
flattened view (you just have to access it explicitly via the API,
navigating the ImportElement/IncludeElement structure). I don't see any
problem going from a Description component to <description> element,
providing we understand/agree on what that means - e.g. while a Description
will show all WSDL components from an underlying hierarchy of imported WSDL
documents, its corresponding DescriptionElement is just the root
<description> in that hierarchy and the Element model API must be used to
access the same information.
Another aspect of this design is that all <description> elements are
treated the same - i.e. you can call toComponent() on any
DescriptionElement an get a Description component back. So let's say WSDL
A imports WSDL B which contains a <description> element with just a single
<interface> element. 'Normally' you would call toComponent() on the
DescriptionElement representing WSDL A and Interfaces property of the
returned Description component would contain the <interface> from WSDL B.
However, you can also call toComponent() on the DescriptionElement
representing WSDL B, but that Description component would contain just one
Interface component and nothing else. There's probably no reason for doing
that, but unless we treat nested <description> elements differently to the
root <description> element in the Element API, there's probably not way to
avoid it. From my interpretation of Part 2, I don't think this violates
the WSDL 2.0 spec.
John Kaputin
Arthur Ryman
<arthur.ryman@gma
il.com> To
woden-dev@ws.apache.org
07/11/2005 21:43 cc
Subject
Please respond to Re: Design change for WSDL
woden-dev Description implementation
John,
I just looked at the new design and I have a question. Description is
actually very different from the other components since it respresents one
or more <description> elements. Doesn't this break the assumption you're
making, i.e. that you can go to a <description> element from a Description
component? I general, there are several <description> elements for a
Description component.
On 11/4/05, Lawrence Mandel <lm...@ca.ibm.com> wrote:
John,
I'm in favour in consolidating the implementation classes wherever it
won't have a negative usability impact (such as when it requires odd or
confusing method names).
As for the documentation you have, I'd encourage you to post what you
have to the Wiki. We can refine it later but at least this will allow
people to take a look at something.
Lawrence
John Kaputin <
KAPUTIN@uk.ibm.com>
To
11/03/2005 04:56 PM woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev Design change for WSDL
Description
implementation
I have just committed change r330632 so that now the Description and
DescriptionElement interfaces are implemented by a single class,
DescriptionImpl. Details of the design change, the rationale and a UML
class diagram are in the attached PDF. Comments welcome.
(See attached file: Design for WSDL Description.pdf)
BTW, I have various fragments of design in Word and UML that I still need
to collate into some design documentation on the website or wiki.
John
Kaputin---------------------------------------------------------------------
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: Design change for WSDL Description implementation
Posted by Arthur Ryman <ar...@gmail.com>.
John,
I just looked at the new design and I have a question. Description is
actually very different from the other components since it respresents one
or more <description> elements. Doesn't this break the assumption you're
making, i.e. that you can go to a <description> element from a Description
component? I general, there are several <description> elements for a
Description component.
On 11/4/05, Lawrence Mandel <lm...@ca.ibm.com> wrote:
>
>
> John,
>
> I'm in favour in consolidating the implementation classes wherever it
> won't have a negative usability impact (such as when it requires odd or
> confusing method names).
>
> As for the documentation you have, I'd encourage you to post what you have
> to the Wiki. We can refine it later but at least this will allow people to
> take a look at something.
>
> Lawrence
>
>
>
>
> *John Kaputin <KA...@uk.ibm.com>*
>
> 11/03/2005 04:56 PM Please respond to
> woden-dev
>
> To
> woden-dev@ws.apache.org cc
> Subject
> Design change for WSDL Description implementation
>
>
>
>
> I have just committed change r330632 so that now the Description and
> DescriptionElement interfaces are implemented by a single class,
> DescriptionImpl. Details of the design change, the rationale and a UML
> class diagram are in the attached PDF. Comments welcome.
>
> (See attached file: Design for WSDL Description.pdf)
>
> BTW, I have various fragments of design in Word and UML that I still need
> to collate into some design documentation on the website or wiki.
>
> John
> Kaputin---------------------------------------------------------------------
> 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: Design change for WSDL Description implementation
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
John,
I'm in favour in consolidating the implementation classes wherever it
won't have a negative usability impact (such as when it requires odd or
confusing method names).
As for the documentation you have, I'd encourage you to post what you have
to the Wiki. We can refine it later but at least this will allow people to
take a look at something.
Lawrence
John Kaputin <KA...@uk.ibm.com>
11/03/2005 04:56 PM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Design change for WSDL Description implementation
I have just committed change r330632 so that now the Description and
DescriptionElement interfaces are implemented by a single class,
DescriptionImpl. Details of the design change, the rationale and a UML
class diagram are in the attached PDF. Comments welcome.
(See attached file: Design for WSDL Description.pdf)
BTW, I have various fragments of design in Word and UML that I still need
to collate into some design documentation on the website or wiki.
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org