Re: Accessing WSDL2 styles in Axis2 codegen emitter templates

[Sanjiva Weerawarana <sa...@opensource.lk>]

Peter Danielsen wrote:
> 
> I'm quite interested in Axis2's plans for the accommodation of 3rd
> party MEPs, styles, and bindings allowed by WSDL2.

We carefully designed Axis2 to support 3rd party MEPs, styles and 
bindings. Please let us know areas where you are having trouble with as 
that shouldn't be the case! Specific suggestions greatly appreciated .. 
and of course code is better!

Thanks,

Sanjiva.
-- 
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

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

Re: Accessing WSDL2 styles in Axis2 codegen emitter templates

[Peter Danielsen <wi...@gmail.com>]

Sanjiva,

Thanks for your reply. Here are some thoughts on improving codegen's
extensibility.  They're from my perspective trying to extend WSDL2.

It would be great to have some documentation describing codegen's
extension architecture.

Woden has a very valuable wiki page at
http://wiki.apache.org/ws/FrontPage/Woden/WSDLExtensions that we used
to successfully add extensions.  For Axis2, we're working our way
through the code to learn how it works.  It would be helpful to have
something like Woden has.  More Javadoc in codegen would also help.

The WSDL2 working group has done a nice job of segregating the work
into the Core spec and the Adjuncts spec.  I think it would be
valuable to reflect this in the code.  As someone trying to extend
codegen, I'd prefer not to modify codegen framework code because it
does most of what I need.  Also, if I change it then I have my own
version and have to periodically check it against the official version
and copy over any bug fixes.  That gets tedious and error-prone
quickly.

It would help to refactor some code to modularize support for the main
extension mechanisms of WSDL2: styles, MEPs, and bindings. Currently,
the code supports those that are defined in WSDL2 Adjuncts, but it's
not easy to add support for others since it's often the case that
codegen framework classes also contain Adjuncts-driven code (e.g. SOAP
and HTTP bindings, MEPs).

Examples are WSDL20ToAxisServiceBuilder and
AxisServiceBasedMultilanguageEmitter.  It might be easier to
understand and maintain the framework classes if logic specific to
Adjuncts items were factored out to classes devoted to them and
invoked via lookups driven by a properties file, like codegen-config.
An example might be a "BindingProcessor" interface with a SOAP
implementation class and an HTTP implementation class.
WSDL20ToAxisServiceBuilder's "processBinding" method could do a lookup
of a binding URI to find a BindingProcessor and delegate the SOAP or
HTTP work to the appropriate BindingProcessor.  I think this would be
preferable to users hand-editing WSDL20ToAxisServiceBuilder.
AxisServiceBasedMultiLanguageEmitter's generateMethodElement has a
similar mixing of framework and Adjuncts work.

A properties file might also be leveraged to register the mapping of
MEP URIs to AxisOperation sub-classes.  This would eliminate the need
for users of the framework to directly modify AxisOperationFactory to
add new <MEP, AxisOperation> mappings.

This thread started with my request to have the value of the WSDL2
"style" attribute available to the XSLT templates.  I like the XSLT
template approach. I believe it can be improved by ensuring that when
the Emitter produces the DOMs for transformation it doesn't assume
that the templates to be used in the next step are those that shipped
with Axis2.  Codegen-config.properties allows users to introduce
others, so I think it's reasonable for template developers to expect
that items defined in WSDL2 Core should be visible somewhere in those
DOMs.  This includes the "style" attribute as well as items like
message labels (see
http://marc.info/?l=axis-dev&m=118019901127507&w=2)

I've covered a lot here and offered some possible solutions, but I
think the first step is to look at the codegen architecture and its
extension development process covering new MEPs, new styles, and new
bindings.  I hope these comments are useful.


Peter


On 6/1/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> Peter Danielsen wrote:
> >
> > I'm quite interested in Axis2's plans for the accommodation of 3rd
> > party MEPs, styles, and bindings allowed by WSDL2.
>
> We carefully designed Axis2 to support 3rd party MEPs, styles and
> bindings. Please let us know areas where you are having trouble with as
> that shouldn't be the case! Specific suggestions greatly appreciated ..
> and of course code is better!
>
> Thanks,
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>

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