ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "FrontPage/Woden/APIReview/OneWsdlApi" by JohnKaputin
Date Thu, 15 Nov 2007 17:16:45 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.

The following page has been changed by JohnKaputin:
http://wiki.apache.org/ws/FrontPage/Woden/APIReview/OneWsdlApi

The comment on the change is:
Edits to API Review issues

------------------------------------------------------------------------------
  
  We need to consider this issue now that the spec is published, but while the Woden API is
not yet finalized. The API will be not be deemed 'stable' until the Woden 1.0 release. There
is no point in continuing with 2 separate WSDL APIs unless we have users that want them separate
or there are fundamental problems that prevent us combining them.  
  
- Some potential problems to consider are:
+ '''Some potential problems to consider are:'''
  
-  * The difference between Description component and <wsdl:description> element.
+ __The difference between Description component and <wsdl:description> element.__
+ 
  This difference is reflected in the Woden API between {{{Description}}} and {{{DescriptionElement}}}.
In the component model, there is a single {{{Description}}} component as the top-level container
for the other WSDL components that make up a service description. There is no notion of composition
via import or include, so there are no nested {{{Description}}} components – just a ‘flattened’
view of the WSDL contained within a single {{{Description}}} component. By comparison, the
WSDL XML infoset supports document composition via {{{<wsdl:import>}}} and {{{<wsdl:include>}}}
elements, so a complete service description may contain multiple {{{<wsdl:description>}}}
elements (e.g. the service WSDL imports the binding WSDL which imports the interface WSDL).
In the Woden Element API this means multiple {{{DescriptionElement}}} linked from a root {{{DescriptionElement}}}
via {{{ImportElement}}} or {{{IncludeElement}}}.
  
  So, {{{Description}}} and {{{DescriptionElement}}} are not the same thing. {{{Description}}}
contains all of the interfaces, bindings and services declared within a top-level or root
{{{<wsdl:description>}}} AND within any imported or included descriptions.  {{{DescriptionElement}}}
represents a single {{{<wsdl:description>}}} element and its directly declared child
elements. If the child elements include {{{<wsdl:import>}}} or {{{<wsdl:include>}}},
the corresponding {{{ImportElement}}} or {{{IncludeElement}}} APIs can be used to navigate
to any nested {{{DescriptionElement}}}s.
  
- It would be easy enough to combine say Binding and BindingElement into a single interface
because they represent the same entity (a single binding) and contain fundamentally the same
content (the same binding faults and operations).  Combining Description and DescriptionElement
requires more thought. Perhaps we could define different sets of methods for ‘get_local_only’
and ‘get_local_and_nested’, with the behaviour of the latter being similar to flattened
properties in the Description component.
+ It would be easy enough to combine say {{{Binding}}} and {{{BindingElement}}} into a single
interface because they represent the same entity (a single binding) and contain fundamentally
the same content (the same binding faults and operations).  Combining {{{Description}}} and
{{{DescriptionElement}}} requires more thought. Perhaps we could define different sets of
methods for ''get_local_only'' and ''get_local_and_nested'', with the behaviour of the latter
being similar to flattened properties in the existing {{{Description}}} component.
  
- Some WSDL infoset not represented in the Component model.
+ __Some of the WSDL infoset not represented in the Component model.__
+ 
  The WSDL elements <documentation>, <import>, <include> and <types>
do not have corresponding WSDL components defined – they are infoset only. Likewise, some
WSDL attributes are not represented directly as Component properties. For example, description’s
targetNamespace is not a Description component property and the messageLabel attribute of
binding fault reference is not a BindingFaultReference property (it is only used to determine
the corresponding interface fault reference). 
  
  If we combine the two APIs, the WSDL component model will be mixed with infoset-specific
content. This only really matters if Woden users care, but it might well complicate usability
for the existing Component API users.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org


Mime
View raw message