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
[EMAIL PROTECTED]
| Kihup Boo/Toronto/[EMAIL PROTECTED]
09/29/2005 03:55 PM
|
|
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
<[EMAIL PROTECTED]
om> To
[email protected]
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/[EMAIL PROTECTED]
MGB To
[email protected]
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
<[EMAIL PROTECTED]>
To
15/09/2005 21:00 [email protected]
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: [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
