What follows is a short example of importing an external schema. You
may also define the schema inline, in which case you should remove the
schemaLocation attribute on the <xsd:import> and just add the
additional <xsd:schema .../> definition to the <wsdl:types>. (you can
define any number of schemas in <wsdl:types>) Notice that in addition
to the import, you must also declare the namespace (ns3). Note that
<xsd:import> imports a namespace, not a schema, so there's an
assumption that the schema that you're importing has a different
targetNamespace. If you wish to include multiple schemas that all have
the same targetNamespace, you must use <xsd:include> rather than
<xsd:import>.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="urn:example:wsdl"
xmlns:ns1="urn:example:wsdl"
xmlns:ns2="urn:example:types"
xmlns:wsdlsoap="
http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="
http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="
http://schemas.xmlsoap.org/wsdl/"
xmlns="
http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<xsd:schema targetNamespace="urn:example:types"
xmlns:ns3="urn:example:schema:foobar">
<xsd:import namespace="urn:example:schema:foobar"
schemaLocation="
http://www.example.com/schemas/foobar.xsd"/>
<xsd:element name="fooMethod">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ns3:foo"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="fooMethodReturn">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ns3:bar"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="fooMethodRequest">
<wsdl:part name="parameters" element="ns2:fooMethod"/>
</wsdl:message>
<wsdl:message name="fooMethodResponse">
<wsdl:part name="parameters" element="ns2:fooMethodReturn"/>
</wsdl:message>
<wsdl:portType name="foo">
<wsdl:operation name="fooMethod">
<wsdl:input name="fooMethodRequest" message="ns1:fooMethodRequest"/>
<wsdl:output name="fooMethodResponse" message="ns1:fooMethodResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="fooSoapBinding" type="ns1:foo">
<wsdlsoap:binding style="document"
transport="
http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="fooMethod">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="fooMethodRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="fooMethodResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>
On 5/4/05, Ryan LeCompte <ryan.lecompte_at_pangonetworks.com> wrote:
> Anne,
>
> Thank you for responding. I recently found an (.NET) article that
> demonstrates what you've just described. I'm going to try it out in the
> coming days and see how it works with code-generation utilities for JWSDP
> and .NET.
>
> Article: http://msdn.microsoft.com/msdnmag/issues/05/03/WSDL/default.aspx
>
> Thanks,
> Ryan
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:atmanes_at_gmail.com]
> Sent: Wednesday, May 04, 2005 12:22 AM
> To: users_at_jax-rpc.dev.java.net
> Subject: Re: Sharing common data types between multiple WSDL files
>
> The proper way to define shared elements and types is to define them
> once in an XML Schema and then import the schema into each WSDL that
> uses the types. (Schemas must be imported using the xsd:import rather
> than the wsdl:import.)
>
> Anne
>
> On 5/3/05, Matt Swensson <matman2k1_at_yahoo.com> wrote:
> > No, they just get repeated in each wsdl.
> >
> > The thing for me is that the provider of the WSDL may have 1 class that
> > all appear the same in the WSDL or actually have different classes in
> > different packages (they are using .NET and don't see their code) that
> > end up appearing with the same definition.
> >
> > In the end, the WSDL's show the same structure and have the same names,
> > but I just use them in different packages on my end as well - I didn't
> > know of a way around it. I make sure to use the package that
> > corresponds to the appropriate service.
> >
> > Wish I could be more help.
> > Matt
> >
> > --- Ryan LeCompte <ryan.lecompte_at_pangonetworks.com> wrote:
> > > Matt,
> > >
> > > You mentioned that you are working with several WSDL files that have
> > > common/shared data types. Does each WSDL refer to a common XML file
> > > that has
> > > the shared data types defined, or does each WSDL file contain a copy
> > > of the
> > > common data type?
> > >
> > > Ryan
> > >
> > > -----Original Message-----
> > > From: Matt Swensson [mailto:matman2k1_at_yahoo.com]
> > > Sent: Tuesday, May 03, 2005 12:29 PM
> > > To: users_at_jax-rpc.dev.java.net
> > > Subject: Re: Sharing common data types between multiple WSDL files
> > >
> > >
> > > I am also in this situation, kind of. I am working with another
> > > party
> > > who is providing the WSDLs to me. There are 3 or 4 of them that I
> > > wscompile into different packages. They have common classes among
> > > each
> > > and I am just left with the same definitions in different packages
> > > for
> > > a number of classes. This doesn't pose a problem for me though, but
> > > like you said may not be too desirable for some.
> > >
> > > You are actually creating the service, so I'm curious to know if
> > > there
> > > is a way to handle this.
> > >
> > > Matt
> > >
> > >
> > >
> > > --- Ryan LeCompte <ryan.lecompte_at_pangonetworks.com> wrote:
> > > > Hello all,
> > > >
> > > >
> > > >
> > > > I have a question regarding "best practices" for sharing similar
> > > data
> > > > types
> > > > among multiple WSDL files. I have a custom data type that multiple
> > > > web
> > > > services will be using. My fear is that I will have to define this
> > > > data type
> > > > in each of the WSDL files for each of the web services. My ultimate
> > > > wish
> > > > would be to define the data type in a single place so that each web
> > > > service's WSDL can reference it. If I define the same data type in
> > > > each of
> > > > the WSDL files, then my fear is that the JWSDP code-generation
> > > > utilities
> > > > (wscompile) will generate duplicate Java objects for the same data
> > > > type in
> > > > different packages. This is definitely not desirable. What is the
> > > > recommended approach when multiple WSDL documents need to
> > > > reference/use a
> > > > common custom data type?
> > > >
> > > >
> > > >
> > > > Any advice is appreciated.
> > > >
> > > >
> > > >
> > > > Thank you,
> > > >
> > > > Ryan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> > > For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> > > For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
> > >
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> > For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>