You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Scott McCoy <ta...@cpan.org> on 2006/02/07 22:55:15 UTC
Confused about more advanced WSDD usage
Hello All,
I am trying to implement a message-style API (as opposed to the
automagical RPC stuff I've seen). I'd like, however, to write my java
service handlers in a more traditional fasion rather than accepting document
fragments and handling them with a bunch of DOM code. So I was doing some
reading about WSDD/WSDL and Schema, and this should be possible. But I'm
not quite sure how it works, and the more I read and look at examples the
more I spin my wheels.
Basically, I have a document fragment like this:
<xsd:complexType name="invoice">
<xsd:attribute name="date" type="xsd:date"/>
<xsd:attribute name="id" type="xsd:integer"/>
<xsd:attribute name="accountid" type="xsd:integer"/>
<!-- An invoice may have one or more line items -->
<xsd:sequence>
<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="purchase" type="xsd:float"/>
<xsd:attribute name="cardnumber" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="balance" type="xsd:float"/>
</xsd:sequence>
</xsd:complexType>
I would like to both return and accept this.
It seems it should be possible, through some magic I don't quite yet
understand, to map a service call to it with the following form:
public <? Dunno> handler (Date date, int id, int accountid, Item[]
lineItems, float balance) {
}
Also, there should be some way to return this from a webservice handler as
well.
Can someone clear up how this works, exactly? Simply defining this
complexType as mapping to a specific method, as above, and being able to
return such a thing.
My next question, is how can I stuff a handler in my request flow that will
read the header and determine weither or not the main service handler is
allowed to be called? I would like to use this for a custom form of
authentication, in which I check the soap envelopes Header before allowing
the soap body elements to get mapped to method calls.
Thanks.
Scott S. McCoy
Re: Confused about more advanced WSDD usage
Posted by Anne Thomas Manes <at...@gmail.com>.
It sounds to me like you didn't define the <wsdl:service> definition
properly.
If you can post your WSDL, I'd be happy to look at it for you.
Anne
On 2/7/06, Scott McCoy <ta...@cpan.org> wrote:
>
> This is quite close to what I am after, I want a properly marked up XML
> Document fragement to be my message.
>
> Imagine your example, except with a few attributes :) The:
>
> <item>
> <attr>1</attr>
> <attr>2</attr>
> </item>
>
> approach to XML I find painful.
>
> We already have documents defined, and I am trying to model our services
> around them.
>
> For instance, we have an invoice document, with an xsd of:
>
> <xsd:element name="invoice" type="invoice"/>
>
> <!-- An invoice is the result of an order -->
> <xsd:complexType name="invoice">
> <xsd:attribute name="date" type="xsd:date"/>
> <xsd:attribute name="id" type="xsd:integer"/>
> <xsd:attribute name="accountid" type="xsd:integer"/>
>
> <!-- An invoice may have one or more line items -->
> <xsd:sequence>
> <xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
> <xsd:complexType>
> <xsd:attribute name="purchase" type="xsd:float"/>
> <xsd:attribute name="cardnumber" type="xsd:string"/>
> </xsd:complexType>
> </xsd:element>
> <!-- An invoice returns an existing balance -->
> <xsd:element name="balance" type="xsd:float"/>
> </xsd:sequence>
> </xsd:complexType>
>
> I would like to return this from my webservice call. It will accept a
> different document type to define the order:
>
> <xsd:element name="order" type="order"/>
>
> <xsd:complexType name="order">
> <xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
> <xsd:complexType>
> <xsd:attribute name="cardid" type="xsd:integer"/>
> <xsd:attribute name="amount" type="xsd:float"/>
> </xsd:complexType>
> </xsd:element
> </xsd:complexType>
>
> I would like to map these, attributes, etc, to service calls in the
> cleanest fasion possible with the most behind the scenes action from Axis
> available.
>
> However, your example seems to not agree with wsdl2java so I'm having
> difficulty seeing how it really works. After the changes made (Which I
> stumbled upon myself but noticed someone had already posted about) that are
> required to make it a valid XML document, it seems to still not be a valid
> WSDL document:
>
> java.io.IOException: Emitter failure. Invalid endpoint address in port
> addSoapPort in service AddServiceLocator: ...
> at org.apache.axis.wsdl.toJava.JavaServiceImplWriter.writeFileBody
> (JavaServiceImplWriter.java :242)
> at org.apache.axis.wsdl.toJava.JavaWriter.generate(JavaWriter.java
> :127)
> at org.apache.axis.wsdl.toJava.JavaServiceWriter.generate(
> JavaServiceWriter.java:112)
> at
> org.apache.axis.wsdl.toJava.JavaGeneratorFactory$Writers.generate (
> JavaGeneratorFactory.java:421)
> at org.apache.axis.wsdl.gen.Parser.generate(Parser.java:476)
> at org.apache.axis.wsdl.gen.Parser.access$000(Parser.java:45)
> at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run (Parser.java
> :362)
> at java.lang.Thread.run(Thread.java:595)
>
>
>
> On 2/7/06, Anne Thomas Manes <atmanes@gmail.com > wrote:
> >
> > I don't understand what you mean.
> >
> > The messaging API (i.e., provider="java:MSG") is a low-level API in
> > which the application programmatically constructs and processes XML messages
> > using DOM. If you don't want to work with DOM, then you shouldn't use the
> > messaging API.
> >
> > To produce a method like this:
> >
> > public invoice handler (Calendar date, int id, int accountid, Item[]
> > lineItems, float balance) {
> > }
> >
> > you need to use the RPC API ( i.e., provider="java:RPC"). The RPC API
> > does automagic mapping of Java objects to XML types. (Note that per the
> > JAX-RPC spec, you should use Calendar instead of Date)
> >
> > Perhaps what you want is to use document style messages as opposed to
> > rpc/encoded? Well -- you still use the RPC API. (Don't you hate these
> > overloaded terms?) The RPC API supports four message styles: rpc/encoded,
> > rpc/literal, wrapped doc/literal, and unwrapped doc/literal. I suspect you
> > want wrapped doc/literal. If you are generating the WSDL then specify
> > style="WRAPPED" in the WSDD. If you are generating code from WSDL, then you
> > have to follow the wrapped convention in your WSDL. See my blog entry for
> > instructions:
> >
> > http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
> >
> >
> >
> > Anne
> >
> > On 2/7/06, Scott McCoy <ta...@cpan.org> wrote:
> > >
> > > Hello All,
> > > I am trying to implement a message-style API (as opposed to the
> > > automagical RPC stuff I've seen). I'd like, however, to write my java
> > > service handlers in a more traditional fasion rather than accepting document
> > > fragments and handling them with a bunch of DOM code. So I was doing some
> > > reading about WSDD/WSDL and Schema, and this should be possible. But I'm
> > > not quite sure how it works, and the more I read and look at examples the
> > > more I spin my wheels.
> > >
> > > Basically, I have a document fragment like this:
> > >
> > >
> > > <xsd:complexType name="invoice">
> > > <xsd:attribute name="date" type="xsd:date"/>
> > > <xsd:attribute name="id" type="xsd:integer"/>
> > > <xsd:attribute name="accountid" type="xsd:integer"/>
> > >
> > > <!-- An invoice may have one or more line items -->
> > > <xsd:sequence>
> > > <xsd:element name="item" minOccurs="0"
> > > maxOccurs="unbounded">
> > > <xsd:complexType>
> > > <xsd:attribute name="purchase" type="xsd:float"/>
> > > <xsd:attribute name="cardnumber"
> > > type="xsd:string"/>
> > > </xsd:complexType>
> > > </xsd:element>
> > > <xsd:element name="balance" type="xsd:float"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > >
> > > I would like to both return and accept this.
> > >
> > > It seems it should be possible, through some magic I don't quite yet
> > > understand, to map a service call to it with the following form:
> > >
> > > public <? Dunno> handler (Date date, int id, int accountid, Item[]
> > > lineItems, float balance) {
> > > }
> > >
> > > Also, there should be some way to return this from a webservice
> > > handler as well.
> > >
> > > Can someone clear up how this works, exactly? Simply defining this
> > > complexType as mapping to a specific method, as above, and being able to
> > > return such a thing.
> > >
> > > My next question, is how can I stuff a handler in my request flow that
> > > will read the header and determine weither or not the main service handler
> > > is allowed to be called? I would like to use this for a custom form of
> > > authentication, in which I check the soap envelopes Header before allowing
> > > the soap body elements to get mapped to method calls.
> > >
> > > Thanks.
> > >
> > > Scott S. McCoy
> > >
> > >
> >
>
Re: Confused about more advanced WSDD usage
Posted by Scott McCoy <ta...@cpan.org>.
This is quite close to what I am after, I want a properly marked up XML
Document fragement to be my message.
Imagine your example, except with a few attributes :) The:
<item>
<attr>1</attr>
<attr>2</attr>
</item>
approach to XML I find painful.
We already have documents defined, and I am trying to model our services
around them.
For instance, we have an invoice document, with an xsd of:
<xsd:element name="invoice" type="invoice"/>
<!-- An invoice is the result of an order -->
<xsd:complexType name="invoice">
<xsd:attribute name="date" type="xsd:date"/>
<xsd:attribute name="id" type="xsd:integer"/>
<xsd:attribute name="accountid" type="xsd:integer"/>
<!-- An invoice may have one or more line items -->
<xsd:sequence>
<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="purchase" type="xsd:float"/>
<xsd:attribute name="cardnumber" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<!-- An invoice returns an existing balance -->
<xsd:element name="balance" type="xsd:float"/>
</xsd:sequence>
</xsd:complexType>
I would like to return this from my webservice call. It will accept a
different document type to define the order:
<xsd:element name="order" type="order"/>
<xsd:complexType name="order">
<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="cardid" type="xsd:integer"/>
<xsd:attribute name="amount" type="xsd:float"/>
</xsd:complexType>
</xsd:element
</xsd:complexType>
I would like to map these, attributes, etc, to service calls in the cleanest
fasion possible with the most behind the scenes action from Axis available.
However, your example seems to not agree with wsdl2java so I'm having
difficulty seeing how it really works. After the changes made (Which I
stumbled upon myself but noticed someone had already posted about) that are
required to make it a valid XML document, it seems to still not be a valid
WSDL document:
java.io.IOException: Emitter failure. Invalid endpoint address in port
addSoapPort in service AddServiceLocator: ...
at org.apache.axis.wsdl.toJava.JavaServiceImplWriter.writeFileBody(
JavaServiceImplWriter.java:242)
at org.apache.axis.wsdl.toJava.JavaWriter.generate(JavaWriter.java
:127)
at org.apache.axis.wsdl.toJava.JavaServiceWriter.generate(
JavaServiceWriter.java:112)
at org.apache.axis.wsdl.toJava.JavaGeneratorFactory$Writers.generate
(JavaGeneratorFactory.java:421)
at org.apache.axis.wsdl.gen.Parser.generate(Parser.java:476)
at org.apache.axis.wsdl.gen.Parser.access$000(Parser.java:45)
at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:362)
at java.lang.Thread.run(Thread.java:595)
On 2/7/06, Anne Thomas Manes <at...@gmail.com> wrote:
>
> I don't understand what you mean.
>
> The messaging API (i.e., provider="java:MSG") is a low-level API in which
> the application programmatically constructs and processes XML messages using
> DOM. If you don't want to work with DOM, then you shouldn't use the
> messaging API.
>
> To produce a method like this:
>
> public invoice handler (Calendar date, int id, int accountid, Item[]
> lineItems, float balance) {
> }
>
> you need to use the RPC API ( i.e., provider="java:RPC"). The RPC API does
> automagic mapping of Java objects to XML types. (Note that per the JAX-RPC
> spec, you should use Calendar instead of Date)
>
> Perhaps what you want is to use document style messages as opposed to
> rpc/encoded? Well -- you still use the RPC API. (Don't you hate these
> overloaded terms?) The RPC API supports four message styles: rpc/encoded,
> rpc/literal, wrapped doc/literal, and unwrapped doc/literal. I suspect you
> want wrapped doc/literal. If you are generating the WSDL then specify
> style="WRAPPED" in the WSDD. If you are generating code from WSDL, then you
> have to follow the wrapped convention in your WSDL. See my blog entry for
> instructions:
>
>
> http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
>
>
> Anne
>
> On 2/7/06, Scott McCoy <ta...@cpan.org> wrote:
> >
> > Hello All,
> > I am trying to implement a message-style API (as opposed to the
> > automagical RPC stuff I've seen). I'd like, however, to write my java
> > service handlers in a more traditional fasion rather than accepting document
> > fragments and handling them with a bunch of DOM code. So I was doing some
> > reading about WSDD/WSDL and Schema, and this should be possible. But I'm
> > not quite sure how it works, and the more I read and look at examples the
> > more I spin my wheels.
> >
> > Basically, I have a document fragment like this:
> >
> >
> > <xsd:complexType name="invoice">
> > <xsd:attribute name="date" type="xsd:date"/>
> > <xsd:attribute name="id" type="xsd:integer"/>
> > <xsd:attribute name="accountid" type="xsd:integer"/>
> >
> > <!-- An invoice may have one or more line items -->
> > <xsd:sequence>
> > <xsd:element name="item" minOccurs="0"
> > maxOccurs="unbounded">
> > <xsd:complexType>
> > <xsd:attribute name="purchase" type="xsd:float"/>
> > <xsd:attribute name="cardnumber" type="xsd:string"/>
> >
> > </xsd:complexType>
> > </xsd:element>
> > <xsd:element name="balance" type="xsd:float"/>
> > </xsd:sequence>
> > </xsd:complexType>
> >
> > I would like to both return and accept this.
> >
> > It seems it should be possible, through some magic I don't quite yet
> > understand, to map a service call to it with the following form:
> >
> > public <? Dunno> handler (Date date, int id, int accountid, Item[]
> > lineItems, float balance) {
> > }
> >
> > Also, there should be some way to return this from a webservice handler
> > as well.
> >
> > Can someone clear up how this works, exactly? Simply defining this
> > complexType as mapping to a specific method, as above, and being able to
> > return such a thing.
> >
> > My next question, is how can I stuff a handler in my request flow that
> > will read the header and determine weither or not the main service handler
> > is allowed to be called? I would like to use this for a custom form of
> > authentication, in which I check the soap envelopes Header before allowing
> > the soap body elements to get mapped to method calls.
> >
> > Thanks.
> >
> > Scott S. McCoy
> >
> >
>
Re: Confused about more advanced WSDD usage
Posted by Anne Thomas Manes <at...@gmail.com>.
I don't understand what you mean.
The messaging API (i.e., provider="java:MSG") is a low-level API in which
the application programmatically constructs and processes XML messages using
DOM. If you don't want to work with DOM, then you shouldn't use the
messaging API.
To produce a method like this:
public invoice handler (Calendar date, int id, int accountid, Item[]
lineItems, float balance) {
}
you need to use the RPC API (i.e., provider="java:RPC"). The RPC API does
automagic mapping of Java objects to XML types. (Note that per the JAX-RPC
spec, you should use Calendar instead of Date)
Perhaps what you want is to use document style messages as opposed to
rpc/encoded? Well -- you still use the RPC API. (Don't you hate these
overloaded terms?) The RPC API supports four message styles: rpc/encoded,
rpc/literal, wrapped doc/literal, and unwrapped doc/literal. I suspect you
want wrapped doc/literal. If you are generating the WSDL then specify
style="WRAPPED" in the WSDD. If you are generating code from WSDL, then you
have to follow the wrapped convention in your WSDL. See my blog entry for
instructions:
http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
Anne
On 2/7/06, Scott McCoy <ta...@cpan.org> wrote:
>
> Hello All,
> I am trying to implement a message-style API (as opposed to the
> automagical RPC stuff I've seen). I'd like, however, to write my java
> service handlers in a more traditional fasion rather than accepting document
> fragments and handling them with a bunch of DOM code. So I was doing some
> reading about WSDD/WSDL and Schema, and this should be possible. But I'm
> not quite sure how it works, and the more I read and look at examples the
> more I spin my wheels.
>
> Basically, I have a document fragment like this:
>
>
> <xsd:complexType name="invoice">
> <xsd:attribute name="date" type="xsd:date"/>
> <xsd:attribute name="id" type="xsd:integer"/>
> <xsd:attribute name="accountid" type="xsd:integer"/>
>
> <!-- An invoice may have one or more line items -->
> <xsd:sequence>
> <xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
> <xsd:complexType>
> <xsd:attribute name="purchase" type="xsd:float"/>
> <xsd:attribute name="cardnumber" type="xsd:string"/>
> </xsd:complexType>
> </xsd:element>
> <xsd:element name="balance" type="xsd:float"/>
> </xsd:sequence>
> </xsd:complexType>
>
> I would like to both return and accept this.
>
> It seems it should be possible, through some magic I don't quite yet
> understand, to map a service call to it with the following form:
>
> public <? Dunno> handler (Date date, int id, int accountid, Item[]
> lineItems, float balance) {
> }
>
> Also, there should be some way to return this from a webservice handler as
> well.
>
> Can someone clear up how this works, exactly? Simply defining this
> complexType as mapping to a specific method, as above, and being able to
> return such a thing.
>
> My next question, is how can I stuff a handler in my request flow that
> will read the header and determine weither or not the main service handler
> is allowed to be called? I would like to use this for a custom form of
> authentication, in which I check the soap envelopes Header before allowing
> the soap body elements to get mapped to method calls.
>
> Thanks.
>
> Scott S. McCoy
>
>