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 Kihup Boo <kb...@ca.ibm.com> on 2005/09/15 22:00:49 UTC
A few questions on Woden API
While browsing through the API packages I found two interesting packages.
One seems to model the WSDL 2.0 components (org.apache.woden.wsdl20) and
the other for WSDL 2.0 elements (org.apache.woden.wsdl20.xml). It was not
difficult to understand the latter, I cannot clearly figure out on the use
of org.apache.woden.wsdl20 that looks read-only.
So a couple of questions:
1) What is the motivation of having two different packages?
2) Are these two packages programmatically accessible each other?
2) How is the model loaded (from a WSDL source) in org.apache.woden.wsdl20?
3) What is a scenario of using the above (2) model - as opposed to using
the element model?
Thanks,
- Kihup
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: A few questions on Woden API
Posted by Kihup Boo <kb...@ca.ibm.com>.
OK, the milestones are what I had missed then :-)
By the way, it would be interesting to see what the public method names
would be in the WSDL elements' interfaces. This might become important
especially in a case where only one underlying implementation is provided
for both interfaces. Or, there may be a limitation that an implementation
cannot have both interfaces in case of method name collisions.
- Kihup
Lawrence
Mandel/Toronto/IB
M@IBMCA To
woden-dev@ws.apache.org
09/30/2005 11:24 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
You're absolutely right. You should and will be able to do get the
interface, binding, and any other information registered with a service
element. The service and binding elements have not yet been completed.
Please refer to the Woden milestone plan [1] for the development schedule.
The service element will be complete in milestone 3, scheduled for Nov. 25.
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@ca.ibm.com
[1] http://incubator.apache.org/woden/dev/1.0/milestoneplan.html
Kihup Boo/Toronto/IBM@IBMCA
To
09/30/2005 10:31 AM woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev Re: A few questions on
Woden API
Hi Lawrence,
2) For instance, I may want to traverse through the entire model
relationships for further processing. By starting from DescriptionElement,
I can go to the point of getting a ServiceElement as described in my
previous posting. However since the ServiceElement does not provide any
methods, how can I get an InterfaceElement or other elements from it?
- Kihup
Lawrence
Mandel/Toronto/IB
M@IBMCA To
woden-dev@ws.apache.org
09/30/2005 01:01 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
Hi Kihup,
1. The component model is really a read only view of the underlying model.
It may make sense for other implementations to only implement the XML
specific API. The component model should then automatically stay in sync
with the XML API using only the public XML API methods.
2. I'm not sure what your question is here. Can you clarify or rephrase?
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@ca.ibm.com
Kihup Boo/Toronto/IBM@IBMCA
To
09/29/2005 03:55 PM woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev Re: A few questions on Woden
API
I thought I understood this stuff but here I am stuck again and need to get
educated once more :-)
1) From an implementer's point of view, is there a restriction such as both
(component and xml model) interfaces should be implemented? It looks like
implementing only one model is not sufficient to be useful.
2) As a user, let's say I get an instance of DescriptionElement loaded from
a WSDL file to start with. I call descriptionElement.getServices() to get
an array of ServiceElement. But with a ServiceElement I cannot do anything
useful. Even if an underlying implementation has both sides of interfaces,
I may not want to cast it to Service apparently. Similar case if I start
with DescriptionImpl instead.
Thanks in advance,
- Kihup
John Kaputin
<KAPUTIN@uk.ibm.c
om> To
woden-dev@ws.apache.org
09/16/2005 07:46 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
One further point...although there are two sets of interfaces representing
the 2 views of the WSDL (i.e. read-only component model vs. read-write XML
model), we will provide just one underlying implementation where there is a
1-to-1 correspondence between the interfaces.
The main difference between the component model and the xml model is to do
with Description. The flattened, abstraction is really in the Description
component. org.apache.woden.wsdl20.xml.DescriptionElement corresponds
1-to-1 to a <wsdl:description> element, while
org.apache.woden.wsdl20.Description may represent multiple
<wsdl:description> elements (e.g. the top-level WSDL and any imported
WSDL).
So, we have two separate implementation classes in
org.apache.woden.internal.wsdl20 for for the Description and
DescriptionElement interfaces (DescriptionImpl and DescriptionElementImpl
respectively).
For the other components in the WSDL component model, we will provide just
one implementation class implementing both the component model interface
and the XML model interface (e.g. InterfaceImpl implements Interface and
InterfaceElement).
John Kaputin
John
Kaputin/UK/IBM@IB
MGB To
woden-dev@ws.apache.org
16/09/2005 10:39 cc
Subject
Please respond to Re: A few questions on Woden API
woden-dev
The W3C WSDL 2.0 spec (Part 1) describes a WSDL component model,
represented in the Woden API by the org.apache.woden.wsdl20 interfaces. For
each WSDL component, the spec also describes its XML representation - these
combined XML representations are captured in Woden by the
org.apache.woden.wsdl20.xml interfaces. The component model is a
flattened, abstract view of the WSDL. 'flattened' in that the notion of
document composition is eliminated from the component model....the
Description component includes the WSDL content of any imported WSDL
documents without exposing any WSDL imports. 'abstract' in that the
component model is concerned with just the WSDL information contained in
the underlying XML (e.g. while element and types information is represented
in the component model in ElementDeclaration and TypeDefinition, the
underlying type system and its structure are not).
Applications needing to query information about a WSDL service can use the
component model without the need to know about non-WSDL details like
navigating composite XML documents. However applications needing to edit
WSDL content and produce WSDL documents will need to deal with details of
the underlying XML, so they can use the XML model.
The strategy in Woden for the DOM implementation is to parse the WSDL XML
into the Woden XML model, then derive the Woden component model from it.
The readWSDL methods in the WSDLReader will probably be overloaded so that
a read-write WSDL application can receive an XML model, while a read-only
WSDL application need only know about the component model. The semantic
validation described in the WSDL 2.0 spec will occur against the component
model (if validation is enabled). The component model will be
programmatically accessible from the XML model. There most probably will be
a programmatic way of accessing the underlying XML model from a component
model too, but we haven't yet considered the use cases or mechanism in any
detail.
The choice of XML parsing will be flexible - we are doing a DOM
implementation initially, but also have a requirement for StAX parsing. We
still need to consider the strategy for instantiating the component and XML
models for StAX and any future implementations.
A milestone plan has just been agreed and should be on the Woden web site
soon. M1 at end of September will contain parsing capability for the Types
and Interface WSDL elements (represented in both the XML and component
models). That might be a good time to try out the code if you are
interested. We will put up some usage documentation around that time too.
Please note that the current code is still very much work-in-progress.
regards,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
15/09/2005 21:00 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev A few questions on Woden API
While browsing through the API packages I found two interesting packages.
One seems to model the WSDL 2.0 components (org.apache.woden.wsdl20) and
the other for WSDL 2.0 elements (org.apache.woden.wsdl20.xml). It was not
difficult to understand the latter, I cannot clearly figure out on the use
of org.apache.woden.wsdl20 that looks read-only.
So a couple of questions:
1) What is the motivation of having two different packages?
2) Are these two packages programmatically accessible each other?
2) How is the model loaded (from a WSDL source) in org.apache.woden.wsdl20?
3) What is a scenario of using the above (2) model - as opposed to using
the element model?
Thanks,
- Kihup
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: A few questions on Woden API
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
You're absolutely right. You should and will be able to do get the
interface, binding, and any other information registered with a service
element. The service and binding elements have not yet been completed.
Please refer to the Woden milestone plan [1] for the development schedule.
The service element will be complete in milestone 3, scheduled for Nov.
25.
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@ca.ibm.com
[1] http://incubator.apache.org/woden/dev/1.0/milestoneplan.html
Kihup Boo/Toronto/IBM@IBMCA
09/30/2005 10:31 AM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Re: A few questions on Woden API
Hi Lawrence,
2) For instance, I may want to traverse through the entire model
relationships for further processing. By starting from DescriptionElement,
I can go to the point of getting a ServiceElement as described in my
previous posting. However since the ServiceElement does not provide any
methods, how can I get an InterfaceElement or other elements from it?
- Kihup
Lawrence
Mandel/Toronto/IB
M@IBMCA To
woden-dev@ws.apache.org
09/30/2005 01:01 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
Hi Kihup,
1. The component model is really a read only view of the underlying model.
It may make sense for other implementations to only implement the XML
specific API. The component model should then automatically stay in sync
with the XML API using only the public XML API methods.
2. I'm not sure what your question is here. Can you clarify or rephrase?
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@ca.ibm.com
Kihup Boo/Toronto/IBM@IBMCA
To
09/29/2005 03:55 PM woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev Re: A few questions on Woden
API
I thought I understood this stuff but here I am stuck again and need to
get
educated once more :-)
1) From an implementer's point of view, is there a restriction such as
both
(component and xml model) interfaces should be implemented? It looks like
implementing only one model is not sufficient to be useful.
2) As a user, let's say I get an instance of DescriptionElement loaded
from
a WSDL file to start with. I call descriptionElement.getServices() to get
an array of ServiceElement. But with a ServiceElement I cannot do anything
useful. Even if an underlying implementation has both sides of interfaces,
I may not want to cast it to Service apparently. Similar case if I start
with DescriptionImpl instead.
Thanks in advance,
- Kihup
John Kaputin
<KAPUTIN@uk.ibm.c
om> To
woden-dev@ws.apache.org
09/16/2005 07:46 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
One further point...although there are two sets of interfaces representing
the 2 views of the WSDL (i.e. read-only component model vs. read-write XML
model), we will provide just one underlying implementation where there is
a
1-to-1 correspondence between the interfaces.
The main difference between the component model and the xml model is to do
with Description. The flattened, abstraction is really in the Description
component. org.apache.woden.wsdl20.xml.DescriptionElement corresponds
1-to-1 to a <wsdl:description> element, while
org.apache.woden.wsdl20.Description may represent multiple
<wsdl:description> elements (e.g. the top-level WSDL and any imported
WSDL).
So, we have two separate implementation classes in
org.apache.woden.internal.wsdl20 for for the Description and
DescriptionElement interfaces (DescriptionImpl and DescriptionElementImpl
respectively).
For the other components in the WSDL component model, we will provide just
one implementation class implementing both the component model interface
and the XML model interface (e.g. InterfaceImpl implements Interface and
InterfaceElement).
John Kaputin
John
Kaputin/UK/IBM@IB
MGB To
woden-dev@ws.apache.org
16/09/2005 10:39 cc
Subject
Please respond to Re: A few questions on Woden API
woden-dev
The W3C WSDL 2.0 spec (Part 1) describes a WSDL component model,
represented in the Woden API by the org.apache.woden.wsdl20 interfaces.
For
each WSDL component, the spec also describes its XML representation -
these
combined XML representations are captured in Woden by the
org.apache.woden.wsdl20.xml interfaces. The component model is a
flattened, abstract view of the WSDL. 'flattened' in that the notion of
document composition is eliminated from the component model....the
Description component includes the WSDL content of any imported WSDL
documents without exposing any WSDL imports. 'abstract' in that the
component model is concerned with just the WSDL information contained in
the underlying XML (e.g. while element and types information is
represented
in the component model in ElementDeclaration and TypeDefinition, the
underlying type system and its structure are not).
Applications needing to query information about a WSDL service can use the
component model without the need to know about non-WSDL details like
navigating composite XML documents. However applications needing to edit
WSDL content and produce WSDL documents will need to deal with details of
the underlying XML, so they can use the XML model.
The strategy in Woden for the DOM implementation is to parse the WSDL XML
into the Woden XML model, then derive the Woden component model from it.
The readWSDL methods in the WSDLReader will probably be overloaded so that
a read-write WSDL application can receive an XML model, while a read-only
WSDL application need only know about the component model. The semantic
validation described in the WSDL 2.0 spec will occur against the component
model (if validation is enabled). The component model will be
programmatically accessible from the XML model. There most probably will
be
a programmatic way of accessing the underlying XML model from a component
model too, but we haven't yet considered the use cases or mechanism in any
detail.
The choice of XML parsing will be flexible - we are doing a DOM
implementation initially, but also have a requirement for StAX parsing. We
still need to consider the strategy for instantiating the component and
XML
models for StAX and any future implementations.
A milestone plan has just been agreed and should be on the Woden web site
soon. M1 at end of September will contain parsing capability for the Types
and Interface WSDL elements (represented in both the XML and component
models). That might be a good time to try out the code if you are
interested. We will put up some usage documentation around that time too.
Please note that the current code is still very much work-in-progress.
regards,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
15/09/2005 21:00 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev A few questions on Woden API
While browsing through the API packages I found two interesting packages.
One seems to model the WSDL 2.0 components (org.apache.woden.wsdl20) and
the other for WSDL 2.0 elements (org.apache.woden.wsdl20.xml). It was not
difficult to understand the latter, I cannot clearly figure out on the use
of org.apache.woden.wsdl20 that looks read-only.
So a couple of questions:
1) What is the motivation of having two different packages?
2) Are these two packages programmatically accessible each other?
2) How is the model loaded (from a WSDL source) in
org.apache.woden.wsdl20?
3) What is a scenario of using the above (2) model - as opposed to using
the element model?
Thanks,
- Kihup
---------------------------------------------------------------------
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: A few questions on Woden API
Posted by Kihup Boo <kb...@ca.ibm.com>.
Hi Lawrence,
2) For instance, I may want to traverse through the entire model
relationships for further processing. By starting from DescriptionElement,
I can go to the point of getting a ServiceElement as described in my
previous posting. However since the ServiceElement does not provide any
methods, how can I get an InterfaceElement or other elements from it?
- Kihup
Lawrence
Mandel/Toronto/IB
M@IBMCA To
woden-dev@ws.apache.org
09/30/2005 01:01 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
Hi Kihup,
1. The component model is really a read only view of the underlying model.
It may make sense for other implementations to only implement the XML
specific API. The component model should then automatically stay in sync
with the XML API using only the public XML API methods.
2. I'm not sure what your question is here. Can you clarify or rephrase?
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@ca.ibm.com
Kihup Boo/Toronto/IBM@IBMCA
To
09/29/2005 03:55 PM woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev Re: A few questions on Woden
API
I thought I understood this stuff but here I am stuck again and need to get
educated once more :-)
1) From an implementer's point of view, is there a restriction such as both
(component and xml model) interfaces should be implemented? It looks like
implementing only one model is not sufficient to be useful.
2) As a user, let's say I get an instance of DescriptionElement loaded from
a WSDL file to start with. I call descriptionElement.getServices() to get
an array of ServiceElement. But with a ServiceElement I cannot do anything
useful. Even if an underlying implementation has both sides of interfaces,
I may not want to cast it to Service apparently. Similar case if I start
with DescriptionImpl instead.
Thanks in advance,
- Kihup
John Kaputin
<KAPUTIN@uk.ibm.c
om> To
woden-dev@ws.apache.org
09/16/2005 07:46 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
One further point...although there are two sets of interfaces representing
the 2 views of the WSDL (i.e. read-only component model vs. read-write XML
model), we will provide just one underlying implementation where there is a
1-to-1 correspondence between the interfaces.
The main difference between the component model and the xml model is to do
with Description. The flattened, abstraction is really in the Description
component. org.apache.woden.wsdl20.xml.DescriptionElement corresponds
1-to-1 to a <wsdl:description> element, while
org.apache.woden.wsdl20.Description may represent multiple
<wsdl:description> elements (e.g. the top-level WSDL and any imported
WSDL).
So, we have two separate implementation classes in
org.apache.woden.internal.wsdl20 for for the Description and
DescriptionElement interfaces (DescriptionImpl and DescriptionElementImpl
respectively).
For the other components in the WSDL component model, we will provide just
one implementation class implementing both the component model interface
and the XML model interface (e.g. InterfaceImpl implements Interface and
InterfaceElement).
John Kaputin
John
Kaputin/UK/IBM@IB
MGB To
woden-dev@ws.apache.org
16/09/2005 10:39 cc
Subject
Please respond to Re: A few questions on Woden API
woden-dev
The W3C WSDL 2.0 spec (Part 1) describes a WSDL component model,
represented in the Woden API by the org.apache.woden.wsdl20 interfaces. For
each WSDL component, the spec also describes its XML representation - these
combined XML representations are captured in Woden by the
org.apache.woden.wsdl20.xml interfaces. The component model is a
flattened, abstract view of the WSDL. 'flattened' in that the notion of
document composition is eliminated from the component model....the
Description component includes the WSDL content of any imported WSDL
documents without exposing any WSDL imports. 'abstract' in that the
component model is concerned with just the WSDL information contained in
the underlying XML (e.g. while element and types information is represented
in the component model in ElementDeclaration and TypeDefinition, the
underlying type system and its structure are not).
Applications needing to query information about a WSDL service can use the
component model without the need to know about non-WSDL details like
navigating composite XML documents. However applications needing to edit
WSDL content and produce WSDL documents will need to deal with details of
the underlying XML, so they can use the XML model.
The strategy in Woden for the DOM implementation is to parse the WSDL XML
into the Woden XML model, then derive the Woden component model from it.
The readWSDL methods in the WSDLReader will probably be overloaded so that
a read-write WSDL application can receive an XML model, while a read-only
WSDL application need only know about the component model. The semantic
validation described in the WSDL 2.0 spec will occur against the component
model (if validation is enabled). The component model will be
programmatically accessible from the XML model. There most probably will be
a programmatic way of accessing the underlying XML model from a component
model too, but we haven't yet considered the use cases or mechanism in any
detail.
The choice of XML parsing will be flexible - we are doing a DOM
implementation initially, but also have a requirement for StAX parsing. We
still need to consider the strategy for instantiating the component and XML
models for StAX and any future implementations.
A milestone plan has just been agreed and should be on the Woden web site
soon. M1 at end of September will contain parsing capability for the Types
and Interface WSDL elements (represented in both the XML and component
models). That might be a good time to try out the code if you are
interested. We will put up some usage documentation around that time too.
Please note that the current code is still very much work-in-progress.
regards,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
15/09/2005 21:00 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev A few questions on Woden API
While browsing through the API packages I found two interesting packages.
One seems to model the WSDL 2.0 components (org.apache.woden.wsdl20) and
the other for WSDL 2.0 elements (org.apache.woden.wsdl20.xml). It was not
difficult to understand the latter, I cannot clearly figure out on the use
of org.apache.woden.wsdl20 that looks read-only.
So a couple of questions:
1) What is the motivation of having two different packages?
2) Are these two packages programmatically accessible each other?
2) How is the model loaded (from a WSDL source) in org.apache.woden.wsdl20?
3) What is a scenario of using the above (2) model - as opposed to using
the element model?
Thanks,
- Kihup
---------------------------------------------------------------------
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: A few questions on Woden API
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
Hi Kihup,
1. The component model is really a read only view of the underlying model.
It may make sense for other implementations to only implement the XML
specific API. The component model should then automatically stay in sync
with the XML API using only the public XML API methods.
2. I'm not sure what your question is here. Can you clarify or rephrase?
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@ca.ibm.com
Kihup Boo/Toronto/IBM@IBMCA
09/29/2005 03:55 PM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Re: A few questions on Woden API
I thought I understood this stuff but here I am stuck again and need to
get
educated once more :-)
1) From an implementer's point of view, is there a restriction such as
both
(component and xml model) interfaces should be implemented? It looks like
implementing only one model is not sufficient to be useful.
2) As a user, let's say I get an instance of DescriptionElement loaded
from
a WSDL file to start with. I call descriptionElement.getServices() to get
an array of ServiceElement. But with a ServiceElement I cannot do anything
useful. Even if an underlying implementation has both sides of interfaces,
I may not want to cast it to Service apparently. Similar case if I start
with DescriptionImpl instead.
Thanks in advance,
- Kihup
John Kaputin
<KAPUTIN@uk.ibm.c
om> To
woden-dev@ws.apache.org
09/16/2005 07:46 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
One further point...although there are two sets of interfaces representing
the 2 views of the WSDL (i.e. read-only component model vs. read-write XML
model), we will provide just one underlying implementation where there is
a
1-to-1 correspondence between the interfaces.
The main difference between the component model and the xml model is to do
with Description. The flattened, abstraction is really in the Description
component. org.apache.woden.wsdl20.xml.DescriptionElement corresponds
1-to-1 to a <wsdl:description> element, while
org.apache.woden.wsdl20.Description may represent multiple
<wsdl:description> elements (e.g. the top-level WSDL and any imported
WSDL).
So, we have two separate implementation classes in
org.apache.woden.internal.wsdl20 for for the Description and
DescriptionElement interfaces (DescriptionImpl and DescriptionElementImpl
respectively).
For the other components in the WSDL component model, we will provide just
one implementation class implementing both the component model interface
and the XML model interface (e.g. InterfaceImpl implements Interface and
InterfaceElement).
John Kaputin
John
Kaputin/UK/IBM@IB
MGB To
woden-dev@ws.apache.org
16/09/2005 10:39 cc
Subject
Please respond to Re: A few questions on Woden API
woden-dev
The W3C WSDL 2.0 spec (Part 1) describes a WSDL component model,
represented in the Woden API by the org.apache.woden.wsdl20 interfaces.
For
each WSDL component, the spec also describes its XML representation -
these
combined XML representations are captured in Woden by the
org.apache.woden.wsdl20.xml interfaces. The component model is a
flattened, abstract view of the WSDL. 'flattened' in that the notion of
document composition is eliminated from the component model....the
Description component includes the WSDL content of any imported WSDL
documents without exposing any WSDL imports. 'abstract' in that the
component model is concerned with just the WSDL information contained in
the underlying XML (e.g. while element and types information is
represented
in the component model in ElementDeclaration and TypeDefinition, the
underlying type system and its structure are not).
Applications needing to query information about a WSDL service can use the
component model without the need to know about non-WSDL details like
navigating composite XML documents. However applications needing to edit
WSDL content and produce WSDL documents will need to deal with details of
the underlying XML, so they can use the XML model.
The strategy in Woden for the DOM implementation is to parse the WSDL XML
into the Woden XML model, then derive the Woden component model from it.
The readWSDL methods in the WSDLReader will probably be overloaded so that
a read-write WSDL application can receive an XML model, while a read-only
WSDL application need only know about the component model. The semantic
validation described in the WSDL 2.0 spec will occur against the component
model (if validation is enabled). The component model will be
programmatically accessible from the XML model. There most probably will
be
a programmatic way of accessing the underlying XML model from a component
model too, but we haven't yet considered the use cases or mechanism in any
detail.
The choice of XML parsing will be flexible - we are doing a DOM
implementation initially, but also have a requirement for StAX parsing. We
still need to consider the strategy for instantiating the component and
XML
models for StAX and any future implementations.
A milestone plan has just been agreed and should be on the Woden web site
soon. M1 at end of September will contain parsing capability for the Types
and Interface WSDL elements (represented in both the XML and component
models). That might be a good time to try out the code if you are
interested. We will put up some usage documentation around that time too.
Please note that the current code is still very much work-in-progress.
regards,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
15/09/2005 21:00 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev A few questions on Woden API
While browsing through the API packages I found two interesting packages.
One seems to model the WSDL 2.0 components (org.apache.woden.wsdl20) and
the other for WSDL 2.0 elements (org.apache.woden.wsdl20.xml). It was not
difficult to understand the latter, I cannot clearly figure out on the use
of org.apache.woden.wsdl20 that looks read-only.
So a couple of questions:
1) What is the motivation of having two different packages?
2) Are these two packages programmatically accessible each other?
2) How is the model loaded (from a WSDL source) in
org.apache.woden.wsdl20?
3) What is a scenario of using the above (2) model - as opposed to using
the element model?
Thanks,
- Kihup
---------------------------------------------------------------------
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: A few questions on Woden API
Posted by Kihup Boo <kb...@ca.ibm.com>.
I thought I understood this stuff but here I am stuck again and need to get
educated once more :-)
1) From an implementer's point of view, is there a restriction such as both
(component and xml model) interfaces should be implemented? It looks like
implementing only one model is not sufficient to be useful.
2) As a user, let's say I get an instance of DescriptionElement loaded from
a WSDL file to start with. I call descriptionElement.getServices() to get
an array of ServiceElement. But with a ServiceElement I cannot do anything
useful. Even if an underlying implementation has both sides of interfaces,
I may not want to cast it to Service apparently. Similar case if I start
with DescriptionImpl instead.
Thanks in advance,
- Kihup
John Kaputin
<KAPUTIN@uk.ibm.c
om> To
woden-dev@ws.apache.org
09/16/2005 07:46 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
One further point...although there are two sets of interfaces representing
the 2 views of the WSDL (i.e. read-only component model vs. read-write XML
model), we will provide just one underlying implementation where there is a
1-to-1 correspondence between the interfaces.
The main difference between the component model and the xml model is to do
with Description. The flattened, abstraction is really in the Description
component. org.apache.woden.wsdl20.xml.DescriptionElement corresponds
1-to-1 to a <wsdl:description> element, while
org.apache.woden.wsdl20.Description may represent multiple
<wsdl:description> elements (e.g. the top-level WSDL and any imported
WSDL).
So, we have two separate implementation classes in
org.apache.woden.internal.wsdl20 for for the Description and
DescriptionElement interfaces (DescriptionImpl and DescriptionElementImpl
respectively).
For the other components in the WSDL component model, we will provide just
one implementation class implementing both the component model interface
and the XML model interface (e.g. InterfaceImpl implements Interface and
InterfaceElement).
John Kaputin
John
Kaputin/UK/IBM@IB
MGB To
woden-dev@ws.apache.org
16/09/2005 10:39 cc
Subject
Please respond to Re: A few questions on Woden API
woden-dev
The W3C WSDL 2.0 spec (Part 1) describes a WSDL component model,
represented in the Woden API by the org.apache.woden.wsdl20 interfaces. For
each WSDL component, the spec also describes its XML representation - these
combined XML representations are captured in Woden by the
org.apache.woden.wsdl20.xml interfaces. The component model is a
flattened, abstract view of the WSDL. 'flattened' in that the notion of
document composition is eliminated from the component model....the
Description component includes the WSDL content of any imported WSDL
documents without exposing any WSDL imports. 'abstract' in that the
component model is concerned with just the WSDL information contained in
the underlying XML (e.g. while element and types information is represented
in the component model in ElementDeclaration and TypeDefinition, the
underlying type system and its structure are not).
Applications needing to query information about a WSDL service can use the
component model without the need to know about non-WSDL details like
navigating composite XML documents. However applications needing to edit
WSDL content and produce WSDL documents will need to deal with details of
the underlying XML, so they can use the XML model.
The strategy in Woden for the DOM implementation is to parse the WSDL XML
into the Woden XML model, then derive the Woden component model from it.
The readWSDL methods in the WSDLReader will probably be overloaded so that
a read-write WSDL application can receive an XML model, while a read-only
WSDL application need only know about the component model. The semantic
validation described in the WSDL 2.0 spec will occur against the component
model (if validation is enabled). The component model will be
programmatically accessible from the XML model. There most probably will be
a programmatic way of accessing the underlying XML model from a component
model too, but we haven't yet considered the use cases or mechanism in any
detail.
The choice of XML parsing will be flexible - we are doing a DOM
implementation initially, but also have a requirement for StAX parsing. We
still need to consider the strategy for instantiating the component and XML
models for StAX and any future implementations.
A milestone plan has just been agreed and should be on the Woden web site
soon. M1 at end of September will contain parsing capability for the Types
and Interface WSDL elements (represented in both the XML and component
models). That might be a good time to try out the code if you are
interested. We will put up some usage documentation around that time too.
Please note that the current code is still very much work-in-progress.
regards,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
15/09/2005 21:00 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev A few questions on Woden API
While browsing through the API packages I found two interesting packages.
One seems to model the WSDL 2.0 components (org.apache.woden.wsdl20) and
the other for WSDL 2.0 elements (org.apache.woden.wsdl20.xml). It was not
difficult to understand the latter, I cannot clearly figure out on the use
of org.apache.woden.wsdl20 that looks read-only.
So a couple of questions:
1) What is the motivation of having two different packages?
2) Are these two packages programmatically accessible each other?
2) How is the model loaded (from a WSDL source) in org.apache.woden.wsdl20?
3) What is a scenario of using the above (2) model - as opposed to using
the element model?
Thanks,
- Kihup
---------------------------------------------------------------------
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: A few questions on Woden API
Posted by Jeremy Hughes <jp...@gmail.com>.
I vote +1 for option 3. We should also compile the API jar (woden-api.jar ?)
separately from the implementation classes to ensure the interface classes
have no compile time dependencies on the implementation. At least that's a
goal anyway.
Jeremy
On 9/16/05, Lawrence Mandel <lm...@ca.ibm.com> wrote:
>
>
> Kihup,
>
> I think there are a few options here.
>
> 1. Package the Woden API and Woden implementation in two jars (as you
> suggested).
> 2. Package the Woden API and Woden implementation in one jar. This
> probably is not a good idea as the idea is that other implementations of the
> Woden API will be created.
> 3. Package the Woden API as one jar and the Woden API + implementation as
> a second jar. This allows those that require the Woden API to just download
> the API while those that want the implementation can download one jar with
> everything they need.
>
> Comments?
>
> Lawrence Mandel
>
> Software Developer
> IBM Rational Software
> Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
> lmandel@ca.ibm.com
>
Re: A few questions on Woden API
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
Kihup,
I think there are a few options here.
1. Package the Woden API and Woden implementation in two jars (as you
suggested).
2. Package the Woden API and Woden implementation in one jar. This
probably is not a good idea as the idea is that other implementations of
the Woden API will be created.
3. Package the Woden API as one jar and the Woden API + implementation as
a second jar. This allows those that require the Woden API to just
download the API while those that want the implementation can download one
jar with everything they need.
Comments?
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@ca.ibm.com
Kihup Boo/Toronto/IBM@IBMCA
09/16/2005 10:16 AM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Re: A few questions on Woden API
That was very clear.
On the packaging side, are you planning to deliver both the interface and
its implementation in a single jar or in two (or more) separate jar files?
I would prefer to have them in separate jar files under the assumption
that
there could be other implementations. I think Xerces does this.
Thanks,
- Kihup
John Kaputin
<KAPUTIN@uk.ibm.c
om> To
woden-dev@ws.apache.org
09/16/2005 07:46 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
One further point...although there are two sets of interfaces representing
the 2 views of the WSDL (i.e. read-only component model vs. read-write XML
model), we will provide just one underlying implementation where there is
a
1-to-1 correspondence between the interfaces.
The main difference between the component model and the xml model is to do
with Description. The flattened, abstraction is really in the Description
component. org.apache.woden.wsdl20.xml.DescriptionElement corresponds
1-to-1 to a <wsdl:description> element, while
org.apache.woden.wsdl20.Description may represent multiple
<wsdl:description> elements (e.g. the top-level WSDL and any imported
WSDL).
So, we have two separate implementation classes in
org.apache.woden.internal.wsdl20 for for the Description and
DescriptionElement interfaces (DescriptionImpl and DescriptionElementImpl
respectively).
For the other components in the WSDL component model, we will provide just
one implementation class implementing both the component model interface
and the XML model interface (e.g. InterfaceImpl implements Interface and
InterfaceElement).
John Kaputin
John
Kaputin/UK/IBM@IB
MGB To
woden-dev@ws.apache.org
16/09/2005 10:39 cc
Subject
Please respond to Re: A few questions on Woden API
woden-dev
The W3C WSDL 2.0 spec (Part 1) describes a WSDL component model,
represented in the Woden API by the org.apache.woden.wsdl20 interfaces.
For
each WSDL component, the spec also describes its XML representation -
these
combined XML representations are captured in Woden by the
org.apache.woden.wsdl20.xml interfaces. The component model is a
flattened, abstract view of the WSDL. 'flattened' in that the notion of
document composition is eliminated from the component model....the
Description component includes the WSDL content of any imported WSDL
documents without exposing any WSDL imports. 'abstract' in that the
component model is concerned with just the WSDL information contained in
the underlying XML (e.g. while element and types information is
represented
in the component model in ElementDeclaration and TypeDefinition, the
underlying type system and its structure are not).
Applications needing to query information about a WSDL service can use the
component model without the need to know about non-WSDL details like
navigating composite XML documents. However applications needing to edit
WSDL content and produce WSDL documents will need to deal with details of
the underlying XML, so they can use the XML model.
The strategy in Woden for the DOM implementation is to parse the WSDL XML
into the Woden XML model, then derive the Woden component model from it.
The readWSDL methods in the WSDLReader will probably be overloaded so that
a read-write WSDL application can receive an XML model, while a read-only
WSDL application need only know about the component model. The semantic
validation described in the WSDL 2.0 spec will occur against the component
model (if validation is enabled). The component model will be
programmatically accessible from the XML model. There most probably will
be
a programmatic way of accessing the underlying XML model from a component
model too, but we haven't yet considered the use cases or mechanism in any
detail.
The choice of XML parsing will be flexible - we are doing a DOM
implementation initially, but also have a requirement for StAX parsing. We
still need to consider the strategy for instantiating the component and
XML
models for StAX and any future implementations.
A milestone plan has just been agreed and should be on the Woden web site
soon. M1 at end of September will contain parsing capability for the Types
and Interface WSDL elements (represented in both the XML and component
models). That might be a good time to try out the code if you are
interested. We will put up some usage documentation around that time too.
Please note that the current code is still very much work-in-progress.
regards,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
15/09/2005 21:00 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev A few questions on Woden API
While browsing through the API packages I found two interesting packages.
One seems to model the WSDL 2.0 components (org.apache.woden.wsdl20) and
the other for WSDL 2.0 elements (org.apache.woden.wsdl20.xml). It was not
difficult to understand the latter, I cannot clearly figure out on the use
of org.apache.woden.wsdl20 that looks read-only.
So a couple of questions:
1) What is the motivation of having two different packages?
2) Are these two packages programmatically accessible each other?
2) How is the model loaded (from a WSDL source) in
org.apache.woden.wsdl20?
3) What is a scenario of using the above (2) model - as opposed to using
the element model?
Thanks,
- Kihup
---------------------------------------------------------------------
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: A few questions on Woden API
Posted by Kihup Boo <kb...@ca.ibm.com>.
That was very clear.
On the packaging side, are you planning to deliver both the interface and
its implementation in a single jar or in two (or more) separate jar files?
I would prefer to have them in separate jar files under the assumption that
there could be other implementations. I think Xerces does this.
Thanks,
- Kihup
John Kaputin
<KAPUTIN@uk.ibm.c
om> To
woden-dev@ws.apache.org
09/16/2005 07:46 cc
AM
Subject
Re: A few questions on Woden API
Please respond to
woden-dev
One further point...although there are two sets of interfaces representing
the 2 views of the WSDL (i.e. read-only component model vs. read-write XML
model), we will provide just one underlying implementation where there is a
1-to-1 correspondence between the interfaces.
The main difference between the component model and the xml model is to do
with Description. The flattened, abstraction is really in the Description
component. org.apache.woden.wsdl20.xml.DescriptionElement corresponds
1-to-1 to a <wsdl:description> element, while
org.apache.woden.wsdl20.Description may represent multiple
<wsdl:description> elements (e.g. the top-level WSDL and any imported
WSDL).
So, we have two separate implementation classes in
org.apache.woden.internal.wsdl20 for for the Description and
DescriptionElement interfaces (DescriptionImpl and DescriptionElementImpl
respectively).
For the other components in the WSDL component model, we will provide just
one implementation class implementing both the component model interface
and the XML model interface (e.g. InterfaceImpl implements Interface and
InterfaceElement).
John Kaputin
John
Kaputin/UK/IBM@IB
MGB To
woden-dev@ws.apache.org
16/09/2005 10:39 cc
Subject
Please respond to Re: A few questions on Woden API
woden-dev
The W3C WSDL 2.0 spec (Part 1) describes a WSDL component model,
represented in the Woden API by the org.apache.woden.wsdl20 interfaces. For
each WSDL component, the spec also describes its XML representation - these
combined XML representations are captured in Woden by the
org.apache.woden.wsdl20.xml interfaces. The component model is a
flattened, abstract view of the WSDL. 'flattened' in that the notion of
document composition is eliminated from the component model....the
Description component includes the WSDL content of any imported WSDL
documents without exposing any WSDL imports. 'abstract' in that the
component model is concerned with just the WSDL information contained in
the underlying XML (e.g. while element and types information is represented
in the component model in ElementDeclaration and TypeDefinition, the
underlying type system and its structure are not).
Applications needing to query information about a WSDL service can use the
component model without the need to know about non-WSDL details like
navigating composite XML documents. However applications needing to edit
WSDL content and produce WSDL documents will need to deal with details of
the underlying XML, so they can use the XML model.
The strategy in Woden for the DOM implementation is to parse the WSDL XML
into the Woden XML model, then derive the Woden component model from it.
The readWSDL methods in the WSDLReader will probably be overloaded so that
a read-write WSDL application can receive an XML model, while a read-only
WSDL application need only know about the component model. The semantic
validation described in the WSDL 2.0 spec will occur against the component
model (if validation is enabled). The component model will be
programmatically accessible from the XML model. There most probably will be
a programmatic way of accessing the underlying XML model from a component
model too, but we haven't yet considered the use cases or mechanism in any
detail.
The choice of XML parsing will be flexible - we are doing a DOM
implementation initially, but also have a requirement for StAX parsing. We
still need to consider the strategy for instantiating the component and XML
models for StAX and any future implementations.
A milestone plan has just been agreed and should be on the Woden web site
soon. M1 at end of September will contain parsing capability for the Types
and Interface WSDL elements (represented in both the XML and component
models). That might be a good time to try out the code if you are
interested. We will put up some usage documentation around that time too.
Please note that the current code is still very much work-in-progress.
regards,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
15/09/2005 21:00 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev A few questions on Woden API
While browsing through the API packages I found two interesting packages.
One seems to model the WSDL 2.0 components (org.apache.woden.wsdl20) and
the other for WSDL 2.0 elements (org.apache.woden.wsdl20.xml). It was not
difficult to understand the latter, I cannot clearly figure out on the use
of org.apache.woden.wsdl20 that looks read-only.
So a couple of questions:
1) What is the motivation of having two different packages?
2) Are these two packages programmatically accessible each other?
2) How is the model loaded (from a WSDL source) in org.apache.woden.wsdl20?
3) What is a scenario of using the above (2) model - as opposed to using
the element model?
Thanks,
- Kihup
---------------------------------------------------------------------
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: A few questions on Woden API
Posted by John Kaputin <KA...@uk.ibm.com>.
One further point...although there are two sets of interfaces representing
the 2 views of the WSDL (i.e. read-only component model vs. read-write XML
model), we will provide just one underlying implementation where there is a
1-to-1 correspondence between the interfaces.
The main difference between the component model and the xml model is to do
with Description. The flattened, abstraction is really in the Description
component. org.apache.woden.wsdl20.xml.DescriptionElement corresponds
1-to-1 to a <wsdl:description> element, while
org.apache.woden.wsdl20.Description may represent multiple
<wsdl:description> elements (e.g. the top-level WSDL and any imported
WSDL).
So, we have two separate implementation classes in
org.apache.woden.internal.wsdl20 for for the Description and
DescriptionElement interfaces (DescriptionImpl and DescriptionElementImpl
respectively).
For the other components in the WSDL component model, we will provide just
one implementation class implementing both the component model interface
and the XML model interface (e.g. InterfaceImpl implements Interface and
InterfaceElement).
John Kaputin
John
Kaputin/UK/IBM@IB
MGB To
woden-dev@ws.apache.org
16/09/2005 10:39 cc
Subject
Please respond to Re: A few questions on Woden API
woden-dev
The W3C WSDL 2.0 spec (Part 1) describes a WSDL component model,
represented in the Woden API by the org.apache.woden.wsdl20 interfaces. For
each WSDL component, the spec also describes its XML representation - these
combined XML representations are captured in Woden by the
org.apache.woden.wsdl20.xml interfaces. The component model is a
flattened, abstract view of the WSDL. 'flattened' in that the notion of
document composition is eliminated from the component model....the
Description component includes the WSDL content of any imported WSDL
documents without exposing any WSDL imports. 'abstract' in that the
component model is concerned with just the WSDL information contained in
the underlying XML (e.g. while element and types information is represented
in the component model in ElementDeclaration and TypeDefinition, the
underlying type system and its structure are not).
Applications needing to query information about a WSDL service can use the
component model without the need to know about non-WSDL details like
navigating composite XML documents. However applications needing to edit
WSDL content and produce WSDL documents will need to deal with details of
the underlying XML, so they can use the XML model.
The strategy in Woden for the DOM implementation is to parse the WSDL XML
into the Woden XML model, then derive the Woden component model from it.
The readWSDL methods in the WSDLReader will probably be overloaded so that
a read-write WSDL application can receive an XML model, while a read-only
WSDL application need only know about the component model. The semantic
validation described in the WSDL 2.0 spec will occur against the component
model (if validation is enabled). The component model will be
programmatically accessible from the XML model. There most probably will be
a programmatic way of accessing the underlying XML model from a component
model too, but we haven't yet considered the use cases or mechanism in any
detail.
The choice of XML parsing will be flexible - we are doing a DOM
implementation initially, but also have a requirement for StAX parsing. We
still need to consider the strategy for instantiating the component and XML
models for StAX and any future implementations.
A milestone plan has just been agreed and should be on the Woden web site
soon. M1 at end of September will contain parsing capability for the Types
and Interface WSDL elements (represented in both the XML and component
models). That might be a good time to try out the code if you are
interested. We will put up some usage documentation around that time too.
Please note that the current code is still very much work-in-progress.
regards,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
15/09/2005 21:00 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev A few questions on Woden API
While browsing through the API packages I found two interesting packages.
One seems to model the WSDL 2.0 components (org.apache.woden.wsdl20) and
the other for WSDL 2.0 elements (org.apache.woden.wsdl20.xml). It was not
difficult to understand the latter, I cannot clearly figure out on the use
of org.apache.woden.wsdl20 that looks read-only.
So a couple of questions:
1) What is the motivation of having two different packages?
2) Are these two packages programmatically accessible each other?
2) How is the model loaded (from a WSDL source) in org.apache.woden.wsdl20?
3) What is a scenario of using the above (2) model - as opposed to using
the element model?
Thanks,
- Kihup
---------------------------------------------------------------------
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: A few questions on Woden API
Posted by John Kaputin <KA...@uk.ibm.com>.
The W3C WSDL 2.0 spec (Part 1) describes a WSDL component model,
represented in the Woden API by the org.apache.woden.wsdl20 interfaces. For
each WSDL component, the spec also describes its XML representation - these
combined XML representations are captured in Woden by the
org.apache.woden.wsdl20.xml interfaces. The component model is a
flattened, abstract view of the WSDL. 'flattened' in that the notion of
document composition is eliminated from the component model....the
Description component includes the WSDL content of any imported WSDL
documents without exposing any WSDL imports. 'abstract' in that the
component model is concerned with just the WSDL information contained in
the underlying XML (e.g. while element and types information is represented
in the component model in ElementDeclaration and TypeDefinition, the
underlying type system and its structure are not).
Applications needing to query information about a WSDL service can use the
component model without the need to know about non-WSDL details like
navigating composite XML documents. However applications needing to edit
WSDL content and produce WSDL documents will need to deal with details of
the underlying XML, so they can use the XML model.
The strategy in Woden for the DOM implementation is to parse the WSDL XML
into the Woden XML model, then derive the Woden component model from it.
The readWSDL methods in the WSDLReader will probably be overloaded so that
a read-write WSDL application can receive an XML model, while a read-only
WSDL application need only know about the component model. The semantic
validation described in the WSDL 2.0 spec will occur against the component
model (if validation is enabled). The component model will be
programmatically accessible from the XML model. There most probably will be
a programmatic way of accessing the underlying XML model from a component
model too, but we haven't yet considered the use cases or mechanism in any
detail.
The choice of XML parsing will be flexible - we are doing a DOM
implementation initially, but also have a requirement for StAX parsing. We
still need to consider the strategy for instantiating the component and XML
models for StAX and any future implementations.
A milestone plan has just been agreed and should be on the Woden web site
soon. M1 at end of September will contain parsing capability for the Types
and Interface WSDL elements (represented in both the XML and component
models). That might be a good time to try out the code if you are
interested. We will put up some usage documentation around that time too.
Please note that the current code is still very much work-in-progress.
regards,
John Kaputin
Kihup Boo
<kb...@ca.ibm.com>
To
15/09/2005 21:00 woden-dev@ws.apache.org
cc
Please respond to Subject
woden-dev A few questions on Woden API
While browsing through the API packages I found two interesting packages.
One seems to model the WSDL 2.0 components (org.apache.woden.wsdl20) and
the other for WSDL 2.0 elements (org.apache.woden.wsdl20.xml). It was not
difficult to understand the latter, I cannot clearly figure out on the use
of org.apache.woden.wsdl20 that looks read-only.
So a couple of questions:
1) What is the motivation of having two different packages?
2) Are these two packages programmatically accessible each other?
2) How is the model loaded (from a WSDL source) in org.apache.woden.wsdl20?
3) What is a scenario of using the above (2) model - as opposed to using
the element model?
Thanks,
- Kihup
---------------------------------------------------------------------
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