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 Arthur Ryman <ar...@gmail.com> on 2006/05/11 04:12:50 UTC
Component Extensions for wsdlx:safe and wrpc:signature
Just a heads up, I noticed we didn't have these extensions defined -
just the one for the SOAP binding.
I'm implementing these.
How's the HTTP binding progressing?
Question: The org.apache.woden.wsdl20.enumeration package contains a
couple of SOAP classes. Shouldn't these bein the SOAP extension
interface package?
My sudden interest in extensions is that we are doing some interop
testing at W3C and I just added extensions to the interchange format
so Woden needs to start outputing these.
-- Arthur
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Component Extensions for wsdlx:safe and wrpc:signature
Posted by Arthur Ryman <ar...@gmail.com>.
John,
I'd like to collaborate on this so that the extension mechanism is
Eclipse-friendly. The mechanism we use in Woden should be able to
support a plug-in approach which means that the extension is described
in a config file and the classes get loaded dynamically. There can be
several extensions points, e.g. new infoset attributes and elements,
new XSD types, new component model components and properties, new
validations rules, etc.
-- Arthur
On 5/21/06, John Kaputin <KA...@uk.ibm.com> wrote:
> Arthur,
> for extension elements and attributes you implement some interfaces (e.g.
> ExtensionElement and ExtensionDeserializer), register those implementations
> via the ExtensionRegistry API then let Woden load the code and invoke the
> appropriate behaviour (e.g. parsing logic in the
> ExtensionDeserializer.unMarshall() method). This is similar to WSDL4J,
> which deals only with infoset extensions (no concept of a Component model
> and component extensions).
>
> The WSDL2.0 spec-defined extensions are pre-registered in the
> PopulatedExtensionRegistry() constructor, but user-defined extensions would
> be registered by the client code. This is something that could be done via
> a config file, but perhaps a better way would be some form of dynamic
> extension discovery similar to that used in WSIF.
>
> The org.apache.woden.xml package is used for extension attributes, but it
> currently supports only the schema simple data types used by the
> spec-defined extension attributes. Perhaps it should support all schema
> simple data types to avoid the need for extension creators to implement the
> XmlAttr interface themselves for any extension attributes that use other
> schema data types.
>
> What makes Woden extension most different to WSDL4J is the need to
> represent the infoset extensions as Component model extensions. First, the
> ComponentExtension interface has to be implemented and registered as above.
> Then once the infoset extensions are parsed and represented in the Element
> model, they need to be 'mapped' to their Component model representation.
> For the spec-defined extensions this is currently done in the
> ComponentBuilder class. Obviously, user-defined extensions should not be
> handled here (i.e. users should not edit the ComponentBuilder class to
> populate their Component extensions from the Element model).
>
> I'm actually hoping to get rid of the ComponentBuilder class and have
> already moved most of its logic into the Impl classes of the wsdl model
> (e.g. Interface, Binding, Property). The only remaining logic is for
> ElementDeclarations and TypeDefinitions and for the component extensions.
> I'll look at moving ElementDeclarations and TypeDefinitions next.
>
> I plan to finish this ComponentBuilder refactoring post-M5 and while doing
> so, will investigate how/where to do this mapping from Element model
> extensions to the Component extensions in a way that makes life simple for
> extension writers. I'll also look at options for extension registration
> via API vs config file vs dynamic discovery. Any collaboration is welcome.
>
> regards,
> John Kaputin
>
>
>
>
> Arthur Ryman
> <ryman@ca.ibm.com
> > To
> woden-dev@ws.apache.org
> 19/05/2006 14:53 cc
> woden-dev@ws.apache.org
> Subject
> Please respond to Re: Component Extensions for
> woden-dev@ws.apac wsdlx:safe and wrpc:signature
> he.org
>
>
>
>
>
>
>
>
>
>
> John,
>
> Thx.
>
> I completed the two extensions.
>
> I think we need to work on the extension design. My naive expectation was
> I'd implement some interface, add an entry to some config file, and then
> Woden would load the code dynamically, like Eclipse does with plug-ins. The
> current design requires me to edit the base Woden code. So Woden has a
> design for extensions but is not truly extensible in the dynamic sense of
> the term.
>
> This is not an immediate concern but we should think about it for the
> future.
>
> Arthur Ryman,
> IBM Software Group, Rational Division
>
> blog: http://ryman.eclipsedevelopersjournal.com/
> phone: +1-905-413-3077, TL 969-3077
> assistant: +1-905-413-2411, TL 969-2411
> fax: +1-905-413-4920, TL 969-4920
> mobile: +1-416-939-5063, text: 4169395063@fido.ca
>
>
> John Kaputin
> <KA...@uk.ibm.com>
> To
> woden-dev@ws.apache.org
> 05/18/2006 12:55 PM cc
>
> Subject
> Please respond to Re: Component Extensions for
> woden-dev@ws.apache.org wsdlx:safe and wrpc:signature
>
>
>
>
>
>
>
>
>
>
>
>
> Arthur,
> sorry for the late reply - I missed this email last week when you sent it.
> HTTP extension are partly done - I got sidetracked early this week by some
> implementation changes and fixing the test cases I broke. Will still be
> done for M5.
>
> The two SOAP enumeration classes probably should be in the
> org.apache.woden.wsdl20.extensions.soap package. I guess I was just
> thinking of putting all the enumeration classes in one 'enumeration'
> package originally, but it makes sense to keep the extensions stuff
> together. Will change this.
>
> I saw your recent commits and wiki updates on the other two extension
> properties. Thanks for these.
>
> regards,
> John Kaputin
>
>
>
>
> "Arthur Ryman"
> <arthur.ryman@gma
> il.com> To
> woden-dev@ws.apache.org
> 11/05/2006 03:12 cc
>
> Subject
> Please respond to Component Extensions for wsdlx:safe
> woden-dev@ws.apac and wrpc:signature
> he.org
>
>
>
>
>
>
>
>
>
> Just a heads up, I noticed we didn't have these extensions defined -
> just the one for the SOAP binding.
>
> I'm implementing these.
>
> How's the HTTP binding progressing?
>
> Question: The org.apache.woden.wsdl20.enumeration package contains a
> couple of SOAP classes. Shouldn't these bein the SOAP extension
> interface package?
>
> My sudden interest in extensions is that we are doing some interop
> testing at W3C and I just added extensions to the interchange format
> so Woden needs to start outputing these.
>
> -- Arthur
>
> ---------------------------------------------------------------------
> 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: Component Extensions for wsdlx:safe and wrpc:signature
Posted by John Kaputin <KA...@uk.ibm.com>.
Arthur,
for extension elements and attributes you implement some interfaces (e.g.
ExtensionElement and ExtensionDeserializer), register those implementations
via the ExtensionRegistry API then let Woden load the code and invoke the
appropriate behaviour (e.g. parsing logic in the
ExtensionDeserializer.unMarshall() method). This is similar to WSDL4J,
which deals only with infoset extensions (no concept of a Component model
and component extensions).
The WSDL2.0 spec-defined extensions are pre-registered in the
PopulatedExtensionRegistry() constructor, but user-defined extensions would
be registered by the client code. This is something that could be done via
a config file, but perhaps a better way would be some form of dynamic
extension discovery similar to that used in WSIF.
The org.apache.woden.xml package is used for extension attributes, but it
currently supports only the schema simple data types used by the
spec-defined extension attributes. Perhaps it should support all schema
simple data types to avoid the need for extension creators to implement the
XmlAttr interface themselves for any extension attributes that use other
schema data types.
What makes Woden extension most different to WSDL4J is the need to
represent the infoset extensions as Component model extensions. First, the
ComponentExtension interface has to be implemented and registered as above.
Then once the infoset extensions are parsed and represented in the Element
model, they need to be 'mapped' to their Component model representation.
For the spec-defined extensions this is currently done in the
ComponentBuilder class. Obviously, user-defined extensions should not be
handled here (i.e. users should not edit the ComponentBuilder class to
populate their Component extensions from the Element model).
I'm actually hoping to get rid of the ComponentBuilder class and have
already moved most of its logic into the Impl classes of the wsdl model
(e.g. Interface, Binding, Property). The only remaining logic is for
ElementDeclarations and TypeDefinitions and for the component extensions.
I'll look at moving ElementDeclarations and TypeDefinitions next.
I plan to finish this ComponentBuilder refactoring post-M5 and while doing
so, will investigate how/where to do this mapping from Element model
extensions to the Component extensions in a way that makes life simple for
extension writers. I'll also look at options for extension registration
via API vs config file vs dynamic discovery. Any collaboration is welcome.
regards,
John Kaputin
Arthur Ryman
<ryman@ca.ibm.com
> To
woden-dev@ws.apache.org
19/05/2006 14:53 cc
woden-dev@ws.apache.org
Subject
Please respond to Re: Component Extensions for
woden-dev@ws.apac wsdlx:safe and wrpc:signature
he.org
John,
Thx.
I completed the two extensions.
I think we need to work on the extension design. My naive expectation was
I'd implement some interface, add an entry to some config file, and then
Woden would load the code dynamically, like Eclipse does with plug-ins. The
current design requires me to edit the base Woden code. So Woden has a
design for extensions but is not truly extensible in the dynamic sense of
the term.
This is not an immediate concern but we should think about it for the
future.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
John Kaputin
<KA...@uk.ibm.com>
To
woden-dev@ws.apache.org
05/18/2006 12:55 PM cc
Subject
Please respond to Re: Component Extensions for
woden-dev@ws.apache.org wsdlx:safe and wrpc:signature
Arthur,
sorry for the late reply - I missed this email last week when you sent it.
HTTP extension are partly done - I got sidetracked early this week by some
implementation changes and fixing the test cases I broke. Will still be
done for M5.
The two SOAP enumeration classes probably should be in the
org.apache.woden.wsdl20.extensions.soap package. I guess I was just
thinking of putting all the enumeration classes in one 'enumeration'
package originally, but it makes sense to keep the extensions stuff
together. Will change this.
I saw your recent commits and wiki updates on the other two extension
properties. Thanks for these.
regards,
John Kaputin
"Arthur Ryman"
<arthur.ryman@gma
il.com> To
woden-dev@ws.apache.org
11/05/2006 03:12 cc
Subject
Please respond to Component Extensions for wsdlx:safe
woden-dev@ws.apac and wrpc:signature
he.org
Just a heads up, I noticed we didn't have these extensions defined -
just the one for the SOAP binding.
I'm implementing these.
How's the HTTP binding progressing?
Question: The org.apache.woden.wsdl20.enumeration package contains a
couple of SOAP classes. Shouldn't these bein the SOAP extension
interface package?
My sudden interest in extensions is that we are doing some interop
testing at W3C and I just added extensions to the interchange format
so Woden needs to start outputing these.
-- Arthur
---------------------------------------------------------------------
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: Component Extensions for wsdlx:safe and wrpc:signature
Posted by Arthur Ryman <ry...@ca.ibm.com>.
John,
Thx.
I completed the two extensions.
I think we need to work on the extension design. My naive expectation was
I'd implement some interface, add an entry to some config file, and then
Woden would load the code dynamically, like Eclipse does with plug-ins.
The current design requires me to edit the base Woden code. So Woden has a
design for extensions but is not truly extensible in the dynamic sense of
the term.
This is not an immediate concern but we should think about it for the
future.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
John Kaputin <KA...@uk.ibm.com>
05/18/2006 12:55 PM
Please respond to
woden-dev@ws.apache.org
To
woden-dev@ws.apache.org
cc
Subject
Re: Component Extensions for wsdlx:safe and wrpc:signature
Arthur,
sorry for the late reply - I missed this email last week when you sent it.
HTTP extension are partly done - I got sidetracked early this week by some
implementation changes and fixing the test cases I broke. Will still be
done for M5.
The two SOAP enumeration classes probably should be in the
org.apache.woden.wsdl20.extensions.soap package. I guess I was just
thinking of putting all the enumeration classes in one 'enumeration'
package originally, but it makes sense to keep the extensions stuff
together. Will change this.
I saw your recent commits and wiki updates on the other two extension
properties. Thanks for these.
regards,
John Kaputin
"Arthur Ryman"
<arthur.ryman@gma
il.com> To
woden-dev@ws.apache.org
11/05/2006 03:12 cc
Subject
Please respond to Component Extensions for wsdlx:safe
woden-dev@ws.apac and wrpc:signature
he.org
Just a heads up, I noticed we didn't have these extensions defined -
just the one for the SOAP binding.
I'm implementing these.
How's the HTTP binding progressing?
Question: The org.apache.woden.wsdl20.enumeration package contains a
couple of SOAP classes. Shouldn't these bein the SOAP extension
interface package?
My sudden interest in extensions is that we are doing some interop
testing at W3C and I just added extensions to the interchange format
so Woden needs to start outputing these.
-- Arthur
---------------------------------------------------------------------
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: Component Extensions for wsdlx:safe and wrpc:signature
Posted by John Kaputin <KA...@uk.ibm.com>.
Arthur,
sorry for the late reply - I missed this email last week when you sent it.
HTTP extension are partly done - I got sidetracked early this week by some
implementation changes and fixing the test cases I broke. Will still be
done for M5.
The two SOAP enumeration classes probably should be in the
org.apache.woden.wsdl20.extensions.soap package. I guess I was just
thinking of putting all the enumeration classes in one 'enumeration'
package originally, but it makes sense to keep the extensions stuff
together. Will change this.
I saw your recent commits and wiki updates on the other two extension
properties. Thanks for these.
regards,
John Kaputin
"Arthur Ryman"
<arthur.ryman@gma
il.com> To
woden-dev@ws.apache.org
11/05/2006 03:12 cc
Subject
Please respond to Component Extensions for wsdlx:safe
woden-dev@ws.apac and wrpc:signature
he.org
Just a heads up, I noticed we didn't have these extensions defined -
just the one for the SOAP binding.
I'm implementing these.
How's the HTTP binding progressing?
Question: The org.apache.woden.wsdl20.enumeration package contains a
couple of SOAP classes. Shouldn't these bein the SOAP extension
interface package?
My sudden interest in extensions is that we are doing some interop
testing at W3C and I just added extensions to the interchange format
so Woden needs to start outputing these.
-- Arthur
---------------------------------------------------------------------
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