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
[EMAIL PROTECTED]
| Kihup Boo/Toronto/[EMAIL PROTECTED]
09/16/2005 10:16 AM
|
|
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
<[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]
