You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@beehive.apache.org by Martin Grotzke <ma...@javakaffee.de> on 2005/08/07 14:17:14 UTC
wsdl/schema generation and custom type mapping
hello,
i'm using beehive for writing some webservices, and like it very
much!
now i want to have a custom type mapping for one class that is used
by more that one webservice in common, but i do not know how to do
this.
what i have is the following:
com.comp.ws.WSConsumerInfo
(this is a class that provides information about the webservice
consumer, this is expected by all webservices)
com.comp.ws.srvc1.WebService1
com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
com.comp.ws.srvc2.WebService2
com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
both webservices define their own targetNamespace, e.g.
"http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
when the wsdl for a service is generated, the serializer creates
only the namespace for the service, and the WSConsumerInfo is
created in the same namespace. so, each webservice gets it's own
WSConsumerInfo, what is not desired, because the client's shall
get the WSConsumerInfo as a shared concept, too.
i'd like to have the WSConsumerInfo generated in a common namespace
"http://ws.comp.com".
is there any way to achieve this with beehive?
thanx for your help,
cheers,
martin
--
Re: wsdl/schema generation and custom type mapping
Posted by Daryoush Mehrtash <dm...@gmail.com>.
We all like simplicity. But one has to measure simplicity not just in
the initial effort, rather on the overall process.
I think what gets lost in the discussions of the web services and SOA
is the significance of having "a Service". For a service that other
applications/services depend on then you need to do lot of up front
planning. To be usable, among other attributes, a service has to be
reliable, secure, performing but also support versioning, and
extensibility which are rather more complicated. In effect when
an organization offers a service it needs the expertise of IT
department (to run the service effectively), Standards body (to define
the service effectively), and Software company (to deal with testing,
upgrades, etc).
Once you move beyond the simple services, I think the least of your
problems is the initial development time (days) . Particularly, when
you amortize the development time over the time a service would be
operational (which hopefully would be in years).
I am very much a practitioner of the Agile methodologies in my
software development. The reason why Agile methodology works better
than the Waterfall model is that, unlike the old days, with modern
IDEs the cost of changing software is a lot less than detailed upfront
design. When you are dealing with a Service, on the other hand, the
cost of change could be enormous and hence you need to spend lot of
time in upfront design of your service.
To define a service not only you should be using schema, but you
should also be looking into defining extensible schemas. For example,
look at the WSDL schema, and how it uses extensibility to define
bindings. It seems to me that defining schema for a seemingly
simple object of a purchase order would be even more complex as it
has to deal with various requirements (address formats, product types,
payment options, etc)
Looking into the crystal ball, my prediction is that SOA best
practices would evolve such that not only you would need start from
Schema but you would also implement the web service more and more in
terms of XML processing (XPath, XQuery, XSLT) rather than Java
programming. Once you start thinking about your interfaces as XML,
then dealing with XML (particularly XML from extensible schema) would
be more effective in XML rather than Java or other similar
programming languages. If you buy that view, then simplicity and
performance would then have to come in XML tooling and processors and
not just how fast you can take a Java interface and convert it to Web
Service.
The saving grace is the Jsr 181, and hopefully JaxB. The idea is
that your service is portable to other implementation means that you
can start designing your service "the right way" with say Beehive
stack, but if it didn't meet your performance requirements you can
move your service to a stack that does. But your investment in the
application development is preserved as the 181 and JaxB would be
portable.
Daryoush
On 8/12/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> hi daryoush,
>
> thanx for the link, indeed some good points!
> i see the reasons for starting from the contract, also the proposed
> alternative (simple, xml/xsd centric soap stack) sounds good!
>
> although, i like the possibility of writing everything in java, so
> that as little as possible turnarounds (or none at all) are required
> to have its webservice written - keeping it as simple as possible.
> (though, one has to know what's good and what should be avoided, but
> this could be provided by an ide-plugin)
> as the language lacks some semantical features compared to xsd, i think
> that it should be possible to use annotations or choose other ways
> correcting this. the only requirement is that it must be as simple as
> possible for the user :)
>
>
> cheers,
> martin
>
>
>
> On Mon, 2005-08-08 at 16:00 -0700, Daryoush Mehrtash wrote:
> > > the possibility of mixing xmlbeans with pojos allows a really fine
> > > grained control over what will be generated in the wsdl.
> > >
> >
> >
> >
> > FYI, you should check out this paper:
> >
> > http://www.hpl.hp.com/techreports/2005/HPL-2005-83.pdf
> >
> > It has a some good points on the importance and power of the XML
> > schema in defining the service.
> >
> > Daryoush
> >
> > On 8/8/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > On Mon, 2005-08-08 at 10:56 -0700, Daryoush Mehrtash wrote:
> > > > On 8/8/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > > > On Sun, 2005-08-07 at 22:58 -0700, Daryoush Mehrtash wrote:
> > > > > > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > > > i have s.th. like the following:
> > > > >
> > > > > package com.comp.ws.srvc1;
> > > > > @WebService(targetNamespace="srvc1.ws.comp.com")
> > > > > class WebService1 {
> > > > > @WebMethod void doFoo( WS1Request req ){}
> > > > > }
> > > > >
> > > > > package com.comp.ws.srvc2;
> > > > > @WebService(targetNamespace="srvc2.ws.comp.com")
> > > > > class WebService2 {
> > > > > @WebMethod void doBar( WS2Request req ){}
> > > > > }
> > > > >
> > > > > where both WS1Request and WS2Request have their domain properties and
> > > > > associate an instance of the class
> > > > > com.comp.ws.WSConsumerInfo.
> > > > > WSConsumerInfo is a technically motivated class that is written once
> > > > > and used for all webservice invokations.
> > > > >
> > > > > the problem now was, that i implemented the getTypeDesc (with namespace
> > > > > "ws.comp.com"), getSerializer and getDeserializer for the
> > > > > WSConsumerInfo, but that this was not enough to get the schema for this
> > > > > class generated in the "ws.comp.com" namespace.
> > > > > to achive this, i had to implement the getTypeDesc etc. in WS1Request
> > > > > and WS2Request, with the _complete_ type description for these classes,
> > > > > with all their properties, that i don't want to customize.
> > > > >
> > > > > i don't understand why i have to write type descriptions for classes
> > > > > that i do not want to customize, why it's not enough to provide this
> > > > > information in the WSConsumerInfo - but this is probably an axis-thing.
> > > > >
> > > >
> > > >
> > > > So you have two classes WS1Request and WS2Request, both of which are
> > > > sub class of WSConsumerInfo
> > > no, they have the WSConsumerInfo as a member variable.
> > >
> > > > and you want to have WSConsumerInfo to
> > > > have common namespace in both web services. Right?
> > > yes, that's right :)
> > >
> > > now i defined common types like WSConsumerInfo in a common namespace
> > > like ws.comp.com in a xsd, and generated xmlbeans from this.
> > > the generated classes then i used as member variables in the WS*Request
> > > (pojos) and it's working, cool! :)
> > > so, when i generate the webservice and let the wsdl/schema be generated,
> > > the common types appear in the correct namespace.
> > >
> > >
> > > > I would also look into the Axis Helper class generation. As I
> > > > mentioned before the Helper classes are designed so that you don't
> > > > have to write your own implementation of the static method. I would
> > > > check with Axis documentation, it may allow you to have fine grain
> > > > control over the namespaces for a parent and parameter types.
> > > thanx for this hint, i'll try this, too.
> > >
> > >
> > > > > again the question concerning jaxb 2.0 and annotations like @XmlType:
> > > > > what do you think of this (in relation to beehive)?
> > > > >
> > > >
> > > > At the moment we don't do anything with jaxb. The way I look at it
> > > > is that once the binding libararies (Axis and XMLBeans, etc) supported
> > > > the JaxB, then it would simplify the beehive in the sense that it
> > > > would let the binding libraries and Axis take care of the XML-Java
> > > > configuration. These issues should not really be dealt with in WSM,
> > > > but for now we need to do the work.
> > > alright, i understand.
> > >
> > >
> > > > Hope it helps
> > >
> > > yes, thanx a lot for your help!
> > > the possibility of mixing xmlbeans with pojos allows a really fine
> > > grained control over what will be generated in the wsdl.
> > >
> > > thanx again,
> > > cheers,
> > > martin
> > >
> > >
> > >
> > > >
> > > > daryoush
> > > > >
> > > > > > There is no need for the wsdd in what you are trying to do. You just
> > > > > > need to figure out what binding (XML-Java) mechanism you want to use
> > > > > > and implement its requirement.
> > > > > >
> > > > > > > currently, i'm a little bit confused if my aims are kind of strange,
> > > > > > > or if in fact it's the best thing to write schema by hand and
> > > > > > > start from this.
> > > > > > > i really wonder why there's no straight forward way in writing
> > > > > > > webservice in plain old java. aren't annotations the thing that
> > > > > > > would enable us to achieve this?
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > It is a valid expectation to be able to write multiple web services
> > > > > > that are using the same underlying types. There is nothing "strange"
> > > > > > about it, it makes a lot of sense, you would want your types to be the
> > > > > > same when you are moving data around services in SOA.
> > > > > >
> > > > > > In WSM you should be able to do exactly that, and do it all in Java.
> > > > > >
> > > > > > > thanx for your help,
> > > > > > > martin
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > You welcome,
> > > > > >
> > > > > > Daryoush
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sun, 2005-08-07 at 11:03 -0700, Daryoush Mehrtash wrote:
> > > > > > > > Martin,
> > > > > > > >
> > > > > > > > Beehive supports three different types in a Web Service.
> > > > > > > >
> > > > > > > > 1. POJO
> > > > > > > > 2. XMLBean types
> > > > > > > > 3. Axis types
> > > > > > > >
> > > > > > > > If you use a POJO as your type, beehive would introspect the class
> > > > > > > > and create its type mappings. It makes your life easier since the
> > > > > > > > introspection walks up the class hierarchy and is smart enough to
> > > > > > > > recognise other Axis or XMLBean types along the way. In this case if
> > > > > > > > you use a same type in two different web services (with different
> > > > > > > > default namespace) you would get different schema. Which is not what
> > > > > > > > you want.
> > > > > > > >
> > > > > > > > The other two alternative (Axis types, and XMLBeans) on the other hand
> > > > > > > > expect the types to do their own serializations. In both of these
> > > > > > > > cases you would be able to get your desired effect, i.e. to reuse the
> > > > > > > > type and still get the same schema.
> > > > > > > >
> > > > > > > > XMLBean types are always generated from schema. They would be an
> > > > > > > > ideal case if you want to start the web service development by
> > > > > > > > defining the schema of the types. You would write your schema and use
> > > > > > > > XMLBean tools to generate the types and then use the types in your web
> > > > > > > > services. You can also take this one step further by using an XML
> > > > > > > > editor to first write the complete WSDL (types, messages, port,
> > > > > > > > binding..) then use beehive to generate your types and the annotated
> > > > > > > > web service class. (see samples/wsm-addressbook-fromWSDL).
> > > > > > > >
> > > > > > > > Your other Alternative is to use Axis types. You would need this if
> > > > > > > > you are using RPC style, or if you want to have fine grain control
> > > > > > > > over the serialization process. You can either write them by hand or
> > > > > > > > use Axis tools to generate the types. This is documented here:
> > > > > > > >
> > > > > > > > http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
> > > > > > > >
> > > > > > > > Note that you would only need the data types that are generated. To
> > > > > > > > write them by hand you would need to implement the three public static
> > > > > > > > methods (getTypeDesc, getSerailizer, and getDeserailizer) for each
> > > > > > > > type. I attached an example for StateType class that was generated
> > > > > > > > by Axis tools, it should give you an idea what you would need to
> > > > > > > > implement. You can drop this class in any JWS, and you should see the
> > > > > > > > type being serialized to http://byXmlBeanNS (just a name i used when i
> > > > > > > > created the type) namespace. Axis also has tools to generate the
> > > > > > > > Helper classes that do serialization (see Axis documentation for more
> > > > > > > > on this).
> > > > > > > >
> > > > > > > > To summarize.... If you are doing RPC style, then use the Axis types
> > > > > > > > (either generated or by hand). If you are using Document style then
> > > > > > > > use XMLBeans if you know the schema of the types, or use Axis types if
> > > > > > > > you want to start from Java and write your own serialization.
> > > > > > > >
> > > > > > > > Hope this helps.
> > > > > > > >
> > > > > > > > Daryoush
> > > > > > > >
> > > > > > > > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > > > > > > hello,
> > > > > > > >
> > > > > > > > what would you think of an additional annotation for the
> > > > > > > > webservice class like @TypeMapping that provides properties
> > > > > > > > like the wsdd-typemapping?
> > > > > > > >
> > > > > > > > i know that this has nothing to do with jsr181 but with axis,
> > > > > > > > but this would be a way to achive more flexibility (concerning
> > > > > > > > things that normally would be done via wsdd)...
> > > > > > > >
> > > > > > > > would this be possible from a technical point of view, and
> > > > > > > > would
> > > > > > > > you integrate things like this into beehive?
> > > > > > > > or what would be the way for customization?
> > > > > > > >
> > > > > > > > cheers,
> > > > > > > > martin
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> > > > > > > > > hello,
> > > > > > > > >
> > > > > > > > > i'm using beehive for writing some webservices, and like it
> > > > > > > > very
> > > > > > > > > much!
> > > > > > > > >
> > > > > > > > > now i want to have a custom type mapping for one class that
> > > > > > > > is used
> > > > > > > > > by more that one webservice in common, but i do not know how
> > > > > > > > to do
> > > > > > > > > this.
> > > > > > > > >
> > > > > > > > > what i have is the following:
> > > > > > > > >
> > > > > > > > > com.comp.ws.WSConsumerInfo
> > > > > > > > > (this is a class that provides information about the
> > > > > > > > webservice
> > > > > > > > > consumer, this is expected by all webservices)
> > > > > > > > >
> > > > > > > > > com.comp.ws.srvc1.WebService1
> > > > > > > > > com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
> > > > > > > > >
> > > > > > > > > com.comp.ws.srvc2.WebService2
> > > > > > > > > com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
> > > > > > > > >
> > > > > > > > > both webservices define their own targetNamespace, e.g.
> > > > > > > > > "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
> > > > > > > > >
> > > > > > > > > when the wsdl for a service is generated, the serializer
> > > > > > > > creates
> > > > > > > > > only the namespace for the service, and the WSConsumerInfo
> > > > > > > > is
> > > > > > > > > created in the same namespace. so, each webservice gets it's
> > > > > > > > own
> > > > > > > > > WSConsumerInfo, what is not desired, because the client's
> > > > > > > > shall
> > > > > > > > > get the WSConsumerInfo as a shared concept, too.
> > > > > > > > > i'd like to have the WSConsumerInfo generated in a common
> > > > > > > > namespace
> > > > > > > > > "http://ws.comp.com".
> > > > > > > > >
> > > > > > > > > is there any way to achieve this with beehive?
> > > > > > > > >
> > > > > > > > > thanx for your help,
> > > > > > > > > cheers,
> > > > > > > > > martin
> > > > > > > > >
> > > > > > > > >
> > > > > > > > --
> > > > > > > > Martin Grotzke
> > > > > > > > Hohenesch 38, 22765 Hamburg
> > > > > > > > Tel. +49 (0) 40.39905668
> > > > > > > > Mobil +49 (0) 170.9365656
> > > > > > > > E-Mail martin.grotzke@javakaffee.de
> > > > > > > > Online http://www.javakaffee.de
> > > > > > > >
> > > > > > > >
> > > > > > > > -----BEGIN PGP SIGNATURE-----
> > > > > > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > > > > > >
> > > > > > > > iD8DBQBC9jSS7FvOl7Te+pYRAuBCAJwPkUSm+dw1h7k
> > > > > > > > ++srrivAfxwIEPACgncgv
> > > > > > > > oVPdxZeypr4wH5Ndf2Yg4FA=
> > > > > > > > =xYUK
> > > > > > > > -----END PGP SIGNATURE-----
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > --
> > > > > > > Martin Grotzke
> > > > > > > Hohenesch 38, 22765 Hamburg
> > > > > > > Tel. +49 (0) 40.39905668
> > > > > > > Mobil +49 (0) 170.9365656
> > > > > > > E-Mail martin.grotzke@javakaffee.de
> > > > > > > Online http://www.javakaffee.de
> > > > > > >
> > > > > > >
> > > > > > > -----BEGIN PGP SIGNATURE-----
> > > > > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > > > > >
> > > > > > > iD8DBQBC9n837FvOl7Te+pYRAhOcAKCdlYE1ewn/L9m4dc6CL71V4EAu1wCgtK2w
> > > > > > > Dgi0xn1we0VzV8/f7mAdj6c=
> > > > > > > =HzL9
> > > > > > > -----END PGP SIGNATURE-----
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > -----BEGIN PGP SIGNATURE-----
> > > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > > >
> > > > > iD4DBQBC9yk97FvOl7Te+pYRAvMqAJi+IBLTqsOhvwj9EgO8M1LhLgw9AJ9VS6WT
> > > > > I/5LW6cKclb+TtAlPBesFw==
> > > > > =ZC3r
> > > > > -----END PGP SIGNATURE-----
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > --
> > > Martin Grotzke
> > > Hohenesch 38, 22765 Hamburg
> > > Tel. +49 (0) 40.39905668
> > > Mobil +49 (0) 170.9365656
> > > E-Mail martin.grotzke@javakaffee.de
> > > Online http://www.javakaffee.de
> > >
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.1 (GNU/Linux)
> > >
> > > iD8DBQBC993I7FvOl7Te+pYRAm9BAJ96OM0P6gm56U+xWm0TyAAXhFnTOwCgkl7Y
> > > +A/7L7F+vnadTSxARk241GU=
> > > =l38C
> > > -----END PGP SIGNATURE-----
> > >
> > >
> > >
> >
> >
> >
> --
> Martin Grotzke
> Hohenesch 38, 22765 Hamburg
> Tel. +49 (0) 40.39905668
> Mobil +49 (0) 170.9365656
> E-Mail martin.grotzke@javakaffee.de
> Online http://www.javakaffee.de
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBC/Ff57FvOl7Te+pYRAmJdAKCmB7DCEGs5hudVCRvI2VkWDQKxcgCfbnnj
> hxCudj9tP/4E4jxWUllCmks=
> =Cy2a
> -----END PGP SIGNATURE-----
>
>
>
--
Daryoush
Weblog: http://perlustration.blogspot.com/
Re: wsdl/schema generation and custom type mapping
Posted by Martin Grotzke <ma...@javakaffee.de>.
hi daryoush,
thanx for the link, indeed some good points!
i see the reasons for starting from the contract, also the proposed
alternative (simple, xml/xsd centric soap stack) sounds good!
although, i like the possibility of writing everything in java, so
that as little as possible turnarounds (or none at all) are required
to have its webservice written - keeping it as simple as possible.
(though, one has to know what's good and what should be avoided, but
this could be provided by an ide-plugin)
as the language lacks some semantical features compared to xsd, i think
that it should be possible to use annotations or choose other ways
correcting this. the only requirement is that it must be as simple as
possible for the user :)
cheers,
martin
On Mon, 2005-08-08 at 16:00 -0700, Daryoush Mehrtash wrote:
> > the possibility of mixing xmlbeans with pojos allows a really fine
> > grained control over what will be generated in the wsdl.
> >
>
>
>
> FYI, you should check out this paper:
>
> http://www.hpl.hp.com/techreports/2005/HPL-2005-83.pdf
>
> It has a some good points on the importance and power of the XML
> schema in defining the service.
>
> Daryoush
>
> On 8/8/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > On Mon, 2005-08-08 at 10:56 -0700, Daryoush Mehrtash wrote:
> > > On 8/8/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > > On Sun, 2005-08-07 at 22:58 -0700, Daryoush Mehrtash wrote:
> > > > > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > > i have s.th. like the following:
> > > >
> > > > package com.comp.ws.srvc1;
> > > > @WebService(targetNamespace="srvc1.ws.comp.com")
> > > > class WebService1 {
> > > > @WebMethod void doFoo( WS1Request req ){}
> > > > }
> > > >
> > > > package com.comp.ws.srvc2;
> > > > @WebService(targetNamespace="srvc2.ws.comp.com")
> > > > class WebService2 {
> > > > @WebMethod void doBar( WS2Request req ){}
> > > > }
> > > >
> > > > where both WS1Request and WS2Request have their domain properties and
> > > > associate an instance of the class
> > > > com.comp.ws.WSConsumerInfo.
> > > > WSConsumerInfo is a technically motivated class that is written once
> > > > and used for all webservice invokations.
> > > >
> > > > the problem now was, that i implemented the getTypeDesc (with namespace
> > > > "ws.comp.com"), getSerializer and getDeserializer for the
> > > > WSConsumerInfo, but that this was not enough to get the schema for this
> > > > class generated in the "ws.comp.com" namespace.
> > > > to achive this, i had to implement the getTypeDesc etc. in WS1Request
> > > > and WS2Request, with the _complete_ type description for these classes,
> > > > with all their properties, that i don't want to customize.
> > > >
> > > > i don't understand why i have to write type descriptions for classes
> > > > that i do not want to customize, why it's not enough to provide this
> > > > information in the WSConsumerInfo - but this is probably an axis-thing.
> > > >
> > >
> > >
> > > So you have two classes WS1Request and WS2Request, both of which are
> > > sub class of WSConsumerInfo
> > no, they have the WSConsumerInfo as a member variable.
> >
> > > and you want to have WSConsumerInfo to
> > > have common namespace in both web services. Right?
> > yes, that's right :)
> >
> > now i defined common types like WSConsumerInfo in a common namespace
> > like ws.comp.com in a xsd, and generated xmlbeans from this.
> > the generated classes then i used as member variables in the WS*Request
> > (pojos) and it's working, cool! :)
> > so, when i generate the webservice and let the wsdl/schema be generated,
> > the common types appear in the correct namespace.
> >
> >
> > > I would also look into the Axis Helper class generation. As I
> > > mentioned before the Helper classes are designed so that you don't
> > > have to write your own implementation of the static method. I would
> > > check with Axis documentation, it may allow you to have fine grain
> > > control over the namespaces for a parent and parameter types.
> > thanx for this hint, i'll try this, too.
> >
> >
> > > > again the question concerning jaxb 2.0 and annotations like @XmlType:
> > > > what do you think of this (in relation to beehive)?
> > > >
> > >
> > > At the moment we don't do anything with jaxb. The way I look at it
> > > is that once the binding libararies (Axis and XMLBeans, etc) supported
> > > the JaxB, then it would simplify the beehive in the sense that it
> > > would let the binding libraries and Axis take care of the XML-Java
> > > configuration. These issues should not really be dealt with in WSM,
> > > but for now we need to do the work.
> > alright, i understand.
> >
> >
> > > Hope it helps
> >
> > yes, thanx a lot for your help!
> > the possibility of mixing xmlbeans with pojos allows a really fine
> > grained control over what will be generated in the wsdl.
> >
> > thanx again,
> > cheers,
> > martin
> >
> >
> >
> > >
> > > daryoush
> > > >
> > > > > There is no need for the wsdd in what you are trying to do. You just
> > > > > need to figure out what binding (XML-Java) mechanism you want to use
> > > > > and implement its requirement.
> > > > >
> > > > > > currently, i'm a little bit confused if my aims are kind of strange,
> > > > > > or if in fact it's the best thing to write schema by hand and
> > > > > > start from this.
> > > > > > i really wonder why there's no straight forward way in writing
> > > > > > webservice in plain old java. aren't annotations the thing that
> > > > > > would enable us to achieve this?
> > > > > >
> > > > > >
> > > > >
> > > > > It is a valid expectation to be able to write multiple web services
> > > > > that are using the same underlying types. There is nothing "strange"
> > > > > about it, it makes a lot of sense, you would want your types to be the
> > > > > same when you are moving data around services in SOA.
> > > > >
> > > > > In WSM you should be able to do exactly that, and do it all in Java.
> > > > >
> > > > > > thanx for your help,
> > > > > > martin
> > > > > >
> > > > > >
> > > > >
> > > > > You welcome,
> > > > >
> > > > > Daryoush
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sun, 2005-08-07 at 11:03 -0700, Daryoush Mehrtash wrote:
> > > > > > > Martin,
> > > > > > >
> > > > > > > Beehive supports three different types in a Web Service.
> > > > > > >
> > > > > > > 1. POJO
> > > > > > > 2. XMLBean types
> > > > > > > 3. Axis types
> > > > > > >
> > > > > > > If you use a POJO as your type, beehive would introspect the class
> > > > > > > and create its type mappings. It makes your life easier since the
> > > > > > > introspection walks up the class hierarchy and is smart enough to
> > > > > > > recognise other Axis or XMLBean types along the way. In this case if
> > > > > > > you use a same type in two different web services (with different
> > > > > > > default namespace) you would get different schema. Which is not what
> > > > > > > you want.
> > > > > > >
> > > > > > > The other two alternative (Axis types, and XMLBeans) on the other hand
> > > > > > > expect the types to do their own serializations. In both of these
> > > > > > > cases you would be able to get your desired effect, i.e. to reuse the
> > > > > > > type and still get the same schema.
> > > > > > >
> > > > > > > XMLBean types are always generated from schema. They would be an
> > > > > > > ideal case if you want to start the web service development by
> > > > > > > defining the schema of the types. You would write your schema and use
> > > > > > > XMLBean tools to generate the types and then use the types in your web
> > > > > > > services. You can also take this one step further by using an XML
> > > > > > > editor to first write the complete WSDL (types, messages, port,
> > > > > > > binding..) then use beehive to generate your types and the annotated
> > > > > > > web service class. (see samples/wsm-addressbook-fromWSDL).
> > > > > > >
> > > > > > > Your other Alternative is to use Axis types. You would need this if
> > > > > > > you are using RPC style, or if you want to have fine grain control
> > > > > > > over the serialization process. You can either write them by hand or
> > > > > > > use Axis tools to generate the types. This is documented here:
> > > > > > >
> > > > > > > http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
> > > > > > >
> > > > > > > Note that you would only need the data types that are generated. To
> > > > > > > write them by hand you would need to implement the three public static
> > > > > > > methods (getTypeDesc, getSerailizer, and getDeserailizer) for each
> > > > > > > type. I attached an example for StateType class that was generated
> > > > > > > by Axis tools, it should give you an idea what you would need to
> > > > > > > implement. You can drop this class in any JWS, and you should see the
> > > > > > > type being serialized to http://byXmlBeanNS (just a name i used when i
> > > > > > > created the type) namespace. Axis also has tools to generate the
> > > > > > > Helper classes that do serialization (see Axis documentation for more
> > > > > > > on this).
> > > > > > >
> > > > > > > To summarize.... If you are doing RPC style, then use the Axis types
> > > > > > > (either generated or by hand). If you are using Document style then
> > > > > > > use XMLBeans if you know the schema of the types, or use Axis types if
> > > > > > > you want to start from Java and write your own serialization.
> > > > > > >
> > > > > > > Hope this helps.
> > > > > > >
> > > > > > > Daryoush
> > > > > > >
> > > > > > > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > > > > > hello,
> > > > > > >
> > > > > > > what would you think of an additional annotation for the
> > > > > > > webservice class like @TypeMapping that provides properties
> > > > > > > like the wsdd-typemapping?
> > > > > > >
> > > > > > > i know that this has nothing to do with jsr181 but with axis,
> > > > > > > but this would be a way to achive more flexibility (concerning
> > > > > > > things that normally would be done via wsdd)...
> > > > > > >
> > > > > > > would this be possible from a technical point of view, and
> > > > > > > would
> > > > > > > you integrate things like this into beehive?
> > > > > > > or what would be the way for customization?
> > > > > > >
> > > > > > > cheers,
> > > > > > > martin
> > > > > > >
> > > > > > >
> > > > > > > On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> > > > > > > > hello,
> > > > > > > >
> > > > > > > > i'm using beehive for writing some webservices, and like it
> > > > > > > very
> > > > > > > > much!
> > > > > > > >
> > > > > > > > now i want to have a custom type mapping for one class that
> > > > > > > is used
> > > > > > > > by more that one webservice in common, but i do not know how
> > > > > > > to do
> > > > > > > > this.
> > > > > > > >
> > > > > > > > what i have is the following:
> > > > > > > >
> > > > > > > > com.comp.ws.WSConsumerInfo
> > > > > > > > (this is a class that provides information about the
> > > > > > > webservice
> > > > > > > > consumer, this is expected by all webservices)
> > > > > > > >
> > > > > > > > com.comp.ws.srvc1.WebService1
> > > > > > > > com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
> > > > > > > >
> > > > > > > > com.comp.ws.srvc2.WebService2
> > > > > > > > com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
> > > > > > > >
> > > > > > > > both webservices define their own targetNamespace, e.g.
> > > > > > > > "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
> > > > > > > >
> > > > > > > > when the wsdl for a service is generated, the serializer
> > > > > > > creates
> > > > > > > > only the namespace for the service, and the WSConsumerInfo
> > > > > > > is
> > > > > > > > created in the same namespace. so, each webservice gets it's
> > > > > > > own
> > > > > > > > WSConsumerInfo, what is not desired, because the client's
> > > > > > > shall
> > > > > > > > get the WSConsumerInfo as a shared concept, too.
> > > > > > > > i'd like to have the WSConsumerInfo generated in a common
> > > > > > > namespace
> > > > > > > > "http://ws.comp.com".
> > > > > > > >
> > > > > > > > is there any way to achieve this with beehive?
> > > > > > > >
> > > > > > > > thanx for your help,
> > > > > > > > cheers,
> > > > > > > > martin
> > > > > > > >
> > > > > > > >
> > > > > > > --
> > > > > > > Martin Grotzke
> > > > > > > Hohenesch 38, 22765 Hamburg
> > > > > > > Tel. +49 (0) 40.39905668
> > > > > > > Mobil +49 (0) 170.9365656
> > > > > > > E-Mail martin.grotzke@javakaffee.de
> > > > > > > Online http://www.javakaffee.de
> > > > > > >
> > > > > > >
> > > > > > > -----BEGIN PGP SIGNATURE-----
> > > > > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > > > > >
> > > > > > > iD8DBQBC9jSS7FvOl7Te+pYRAuBCAJwPkUSm+dw1h7k
> > > > > > > ++srrivAfxwIEPACgncgv
> > > > > > > oVPdxZeypr4wH5Ndf2Yg4FA=
> > > > > > > =xYUK
> > > > > > > -----END PGP SIGNATURE-----
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > --
> > > > > > Martin Grotzke
> > > > > > Hohenesch 38, 22765 Hamburg
> > > > > > Tel. +49 (0) 40.39905668
> > > > > > Mobil +49 (0) 170.9365656
> > > > > > E-Mail martin.grotzke@javakaffee.de
> > > > > > Online http://www.javakaffee.de
> > > > > >
> > > > > >
> > > > > > -----BEGIN PGP SIGNATURE-----
> > > > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > > > >
> > > > > > iD8DBQBC9n837FvOl7Te+pYRAhOcAKCdlYE1ewn/L9m4dc6CL71V4EAu1wCgtK2w
> > > > > > Dgi0xn1we0VzV8/f7mAdj6c=
> > > > > > =HzL9
> > > > > > -----END PGP SIGNATURE-----
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > >
> > > > iD4DBQBC9yk97FvOl7Te+pYRAvMqAJi+IBLTqsOhvwj9EgO8M1LhLgw9AJ9VS6WT
> > > > I/5LW6cKclb+TtAlPBesFw==
> > > > =ZC3r
> > > > -----END PGP SIGNATURE-----
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > --
> > Martin Grotzke
> > Hohenesch 38, 22765 Hamburg
> > Tel. +49 (0) 40.39905668
> > Mobil +49 (0) 170.9365656
> > E-Mail martin.grotzke@javakaffee.de
> > Online http://www.javakaffee.de
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> >
> > iD8DBQBC993I7FvOl7Te+pYRAm9BAJ96OM0P6gm56U+xWm0TyAAXhFnTOwCgkl7Y
> > +A/7L7F+vnadTSxARk241GU=
> > =l38C
> > -----END PGP SIGNATURE-----
> >
> >
> >
>
>
>
--
Martin Grotzke
Hohenesch 38, 22765 Hamburg
Tel. +49 (0) 40.39905668
Mobil +49 (0) 170.9365656
E-Mail martin.grotzke@javakaffee.de
Online http://www.javakaffee.de
Re: wsdl/schema generation and custom type mapping
Posted by Daryoush Mehrtash <dm...@gmail.com>.
> the possibility of mixing xmlbeans with pojos allows a really fine
> grained control over what will be generated in the wsdl.
>
FYI, you should check out this paper:
http://www.hpl.hp.com/techreports/2005/HPL-2005-83.pdf
It has a some good points on the importance and power of the XML
schema in defining the service.
Daryoush
On 8/8/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> On Mon, 2005-08-08 at 10:56 -0700, Daryoush Mehrtash wrote:
> > On 8/8/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > On Sun, 2005-08-07 at 22:58 -0700, Daryoush Mehrtash wrote:
> > > > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > i have s.th. like the following:
> > >
> > > package com.comp.ws.srvc1;
> > > @WebService(targetNamespace="srvc1.ws.comp.com")
> > > class WebService1 {
> > > @WebMethod void doFoo( WS1Request req ){}
> > > }
> > >
> > > package com.comp.ws.srvc2;
> > > @WebService(targetNamespace="srvc2.ws.comp.com")
> > > class WebService2 {
> > > @WebMethod void doBar( WS2Request req ){}
> > > }
> > >
> > > where both WS1Request and WS2Request have their domain properties and
> > > associate an instance of the class
> > > com.comp.ws.WSConsumerInfo.
> > > WSConsumerInfo is a technically motivated class that is written once
> > > and used for all webservice invokations.
> > >
> > > the problem now was, that i implemented the getTypeDesc (with namespace
> > > "ws.comp.com"), getSerializer and getDeserializer for the
> > > WSConsumerInfo, but that this was not enough to get the schema for this
> > > class generated in the "ws.comp.com" namespace.
> > > to achive this, i had to implement the getTypeDesc etc. in WS1Request
> > > and WS2Request, with the _complete_ type description for these classes,
> > > with all their properties, that i don't want to customize.
> > >
> > > i don't understand why i have to write type descriptions for classes
> > > that i do not want to customize, why it's not enough to provide this
> > > information in the WSConsumerInfo - but this is probably an axis-thing.
> > >
> >
> >
> > So you have two classes WS1Request and WS2Request, both of which are
> > sub class of WSConsumerInfo
> no, they have the WSConsumerInfo as a member variable.
>
> > and you want to have WSConsumerInfo to
> > have common namespace in both web services. Right?
> yes, that's right :)
>
> now i defined common types like WSConsumerInfo in a common namespace
> like ws.comp.com in a xsd, and generated xmlbeans from this.
> the generated classes then i used as member variables in the WS*Request
> (pojos) and it's working, cool! :)
> so, when i generate the webservice and let the wsdl/schema be generated,
> the common types appear in the correct namespace.
>
>
> > I would also look into the Axis Helper class generation. As I
> > mentioned before the Helper classes are designed so that you don't
> > have to write your own implementation of the static method. I would
> > check with Axis documentation, it may allow you to have fine grain
> > control over the namespaces for a parent and parameter types.
> thanx for this hint, i'll try this, too.
>
>
> > > again the question concerning jaxb 2.0 and annotations like @XmlType:
> > > what do you think of this (in relation to beehive)?
> > >
> >
> > At the moment we don't do anything with jaxb. The way I look at it
> > is that once the binding libararies (Axis and XMLBeans, etc) supported
> > the JaxB, then it would simplify the beehive in the sense that it
> > would let the binding libraries and Axis take care of the XML-Java
> > configuration. These issues should not really be dealt with in WSM,
> > but for now we need to do the work.
> alright, i understand.
>
>
> > Hope it helps
>
> yes, thanx a lot for your help!
> the possibility of mixing xmlbeans with pojos allows a really fine
> grained control over what will be generated in the wsdl.
>
> thanx again,
> cheers,
> martin
>
>
>
> >
> > daryoush
> > >
> > > > There is no need for the wsdd in what you are trying to do. You just
> > > > need to figure out what binding (XML-Java) mechanism you want to use
> > > > and implement its requirement.
> > > >
> > > > > currently, i'm a little bit confused if my aims are kind of strange,
> > > > > or if in fact it's the best thing to write schema by hand and
> > > > > start from this.
> > > > > i really wonder why there's no straight forward way in writing
> > > > > webservice in plain old java. aren't annotations the thing that
> > > > > would enable us to achieve this?
> > > > >
> > > > >
> > > >
> > > > It is a valid expectation to be able to write multiple web services
> > > > that are using the same underlying types. There is nothing "strange"
> > > > about it, it makes a lot of sense, you would want your types to be the
> > > > same when you are moving data around services in SOA.
> > > >
> > > > In WSM you should be able to do exactly that, and do it all in Java.
> > > >
> > > > > thanx for your help,
> > > > > martin
> > > > >
> > > > >
> > > >
> > > > You welcome,
> > > >
> > > > Daryoush
> > > > >
> > > > >
> > > > >
> > > > > On Sun, 2005-08-07 at 11:03 -0700, Daryoush Mehrtash wrote:
> > > > > > Martin,
> > > > > >
> > > > > > Beehive supports three different types in a Web Service.
> > > > > >
> > > > > > 1. POJO
> > > > > > 2. XMLBean types
> > > > > > 3. Axis types
> > > > > >
> > > > > > If you use a POJO as your type, beehive would introspect the class
> > > > > > and create its type mappings. It makes your life easier since the
> > > > > > introspection walks up the class hierarchy and is smart enough to
> > > > > > recognise other Axis or XMLBean types along the way. In this case if
> > > > > > you use a same type in two different web services (with different
> > > > > > default namespace) you would get different schema. Which is not what
> > > > > > you want.
> > > > > >
> > > > > > The other two alternative (Axis types, and XMLBeans) on the other hand
> > > > > > expect the types to do their own serializations. In both of these
> > > > > > cases you would be able to get your desired effect, i.e. to reuse the
> > > > > > type and still get the same schema.
> > > > > >
> > > > > > XMLBean types are always generated from schema. They would be an
> > > > > > ideal case if you want to start the web service development by
> > > > > > defining the schema of the types. You would write your schema and use
> > > > > > XMLBean tools to generate the types and then use the types in your web
> > > > > > services. You can also take this one step further by using an XML
> > > > > > editor to first write the complete WSDL (types, messages, port,
> > > > > > binding..) then use beehive to generate your types and the annotated
> > > > > > web service class. (see samples/wsm-addressbook-fromWSDL).
> > > > > >
> > > > > > Your other Alternative is to use Axis types. You would need this if
> > > > > > you are using RPC style, or if you want to have fine grain control
> > > > > > over the serialization process. You can either write them by hand or
> > > > > > use Axis tools to generate the types. This is documented here:
> > > > > >
> > > > > > http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
> > > > > >
> > > > > > Note that you would only need the data types that are generated. To
> > > > > > write them by hand you would need to implement the three public static
> > > > > > methods (getTypeDesc, getSerailizer, and getDeserailizer) for each
> > > > > > type. I attached an example for StateType class that was generated
> > > > > > by Axis tools, it should give you an idea what you would need to
> > > > > > implement. You can drop this class in any JWS, and you should see the
> > > > > > type being serialized to http://byXmlBeanNS (just a name i used when i
> > > > > > created the type) namespace. Axis also has tools to generate the
> > > > > > Helper classes that do serialization (see Axis documentation for more
> > > > > > on this).
> > > > > >
> > > > > > To summarize.... If you are doing RPC style, then use the Axis types
> > > > > > (either generated or by hand). If you are using Document style then
> > > > > > use XMLBeans if you know the schema of the types, or use Axis types if
> > > > > > you want to start from Java and write your own serialization.
> > > > > >
> > > > > > Hope this helps.
> > > > > >
> > > > > > Daryoush
> > > > > >
> > > > > > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > > > > hello,
> > > > > >
> > > > > > what would you think of an additional annotation for the
> > > > > > webservice class like @TypeMapping that provides properties
> > > > > > like the wsdd-typemapping?
> > > > > >
> > > > > > i know that this has nothing to do with jsr181 but with axis,
> > > > > > but this would be a way to achive more flexibility (concerning
> > > > > > things that normally would be done via wsdd)...
> > > > > >
> > > > > > would this be possible from a technical point of view, and
> > > > > > would
> > > > > > you integrate things like this into beehive?
> > > > > > or what would be the way for customization?
> > > > > >
> > > > > > cheers,
> > > > > > martin
> > > > > >
> > > > > >
> > > > > > On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> > > > > > > hello,
> > > > > > >
> > > > > > > i'm using beehive for writing some webservices, and like it
> > > > > > very
> > > > > > > much!
> > > > > > >
> > > > > > > now i want to have a custom type mapping for one class that
> > > > > > is used
> > > > > > > by more that one webservice in common, but i do not know how
> > > > > > to do
> > > > > > > this.
> > > > > > >
> > > > > > > what i have is the following:
> > > > > > >
> > > > > > > com.comp.ws.WSConsumerInfo
> > > > > > > (this is a class that provides information about the
> > > > > > webservice
> > > > > > > consumer, this is expected by all webservices)
> > > > > > >
> > > > > > > com.comp.ws.srvc1.WebService1
> > > > > > > com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
> > > > > > >
> > > > > > > com.comp.ws.srvc2.WebService2
> > > > > > > com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
> > > > > > >
> > > > > > > both webservices define their own targetNamespace, e.g.
> > > > > > > "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
> > > > > > >
> > > > > > > when the wsdl for a service is generated, the serializer
> > > > > > creates
> > > > > > > only the namespace for the service, and the WSConsumerInfo
> > > > > > is
> > > > > > > created in the same namespace. so, each webservice gets it's
> > > > > > own
> > > > > > > WSConsumerInfo, what is not desired, because the client's
> > > > > > shall
> > > > > > > get the WSConsumerInfo as a shared concept, too.
> > > > > > > i'd like to have the WSConsumerInfo generated in a common
> > > > > > namespace
> > > > > > > "http://ws.comp.com".
> > > > > > >
> > > > > > > is there any way to achieve this with beehive?
> > > > > > >
> > > > > > > thanx for your help,
> > > > > > > cheers,
> > > > > > > martin
> > > > > > >
> > > > > > >
> > > > > > --
> > > > > > Martin Grotzke
> > > > > > Hohenesch 38, 22765 Hamburg
> > > > > > Tel. +49 (0) 40.39905668
> > > > > > Mobil +49 (0) 170.9365656
> > > > > > E-Mail martin.grotzke@javakaffee.de
> > > > > > Online http://www.javakaffee.de
> > > > > >
> > > > > >
> > > > > > -----BEGIN PGP SIGNATURE-----
> > > > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > > > >
> > > > > > iD8DBQBC9jSS7FvOl7Te+pYRAuBCAJwPkUSm+dw1h7k
> > > > > > ++srrivAfxwIEPACgncgv
> > > > > > oVPdxZeypr4wH5Ndf2Yg4FA=
> > > > > > =xYUK
> > > > > > -----END PGP SIGNATURE-----
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > --
> > > > > Martin Grotzke
> > > > > Hohenesch 38, 22765 Hamburg
> > > > > Tel. +49 (0) 40.39905668
> > > > > Mobil +49 (0) 170.9365656
> > > > > E-Mail martin.grotzke@javakaffee.de
> > > > > Online http://www.javakaffee.de
> > > > >
> > > > >
> > > > > -----BEGIN PGP SIGNATURE-----
> > > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > > >
> > > > > iD8DBQBC9n837FvOl7Te+pYRAhOcAKCdlYE1ewn/L9m4dc6CL71V4EAu1wCgtK2w
> > > > > Dgi0xn1we0VzV8/f7mAdj6c=
> > > > > =HzL9
> > > > > -----END PGP SIGNATURE-----
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.1 (GNU/Linux)
> > >
> > > iD4DBQBC9yk97FvOl7Te+pYRAvMqAJi+IBLTqsOhvwj9EgO8M1LhLgw9AJ9VS6WT
> > > I/5LW6cKclb+TtAlPBesFw==
> > > =ZC3r
> > > -----END PGP SIGNATURE-----
> > >
> > >
> > >
> >
> >
> >
> --
> Martin Grotzke
> Hohenesch 38, 22765 Hamburg
> Tel. +49 (0) 40.39905668
> Mobil +49 (0) 170.9365656
> E-Mail martin.grotzke@javakaffee.de
> Online http://www.javakaffee.de
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBC993I7FvOl7Te+pYRAm9BAJ96OM0P6gm56U+xWm0TyAAXhFnTOwCgkl7Y
> +A/7L7F+vnadTSxARk241GU=
> =l38C
> -----END PGP SIGNATURE-----
>
>
>
--
Daryoush
Weblog: http://perlustration.blogspot.com/
Re: wsdl/schema generation and custom type mapping
Posted by Martin Grotzke <ma...@javakaffee.de>.
On Mon, 2005-08-08 at 10:56 -0700, Daryoush Mehrtash wrote:
> On 8/8/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > On Sun, 2005-08-07 at 22:58 -0700, Daryoush Mehrtash wrote:
> > > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > i have s.th. like the following:
> >
> > package com.comp.ws.srvc1;
> > @WebService(targetNamespace="srvc1.ws.comp.com")
> > class WebService1 {
> > @WebMethod void doFoo( WS1Request req ){}
> > }
> >
> > package com.comp.ws.srvc2;
> > @WebService(targetNamespace="srvc2.ws.comp.com")
> > class WebService2 {
> > @WebMethod void doBar( WS2Request req ){}
> > }
> >
> > where both WS1Request and WS2Request have their domain properties and
> > associate an instance of the class
> > com.comp.ws.WSConsumerInfo.
> > WSConsumerInfo is a technically motivated class that is written once
> > and used for all webservice invokations.
> >
> > the problem now was, that i implemented the getTypeDesc (with namespace
> > "ws.comp.com"), getSerializer and getDeserializer for the
> > WSConsumerInfo, but that this was not enough to get the schema for this
> > class generated in the "ws.comp.com" namespace.
> > to achive this, i had to implement the getTypeDesc etc. in WS1Request
> > and WS2Request, with the _complete_ type description for these classes,
> > with all their properties, that i don't want to customize.
> >
> > i don't understand why i have to write type descriptions for classes
> > that i do not want to customize, why it's not enough to provide this
> > information in the WSConsumerInfo - but this is probably an axis-thing.
> >
>
>
> So you have two classes WS1Request and WS2Request, both of which are
> sub class of WSConsumerInfo
no, they have the WSConsumerInfo as a member variable.
> and you want to have WSConsumerInfo to
> have common namespace in both web services. Right?
yes, that's right :)
now i defined common types like WSConsumerInfo in a common namespace
like ws.comp.com in a xsd, and generated xmlbeans from this.
the generated classes then i used as member variables in the WS*Request
(pojos) and it's working, cool! :)
so, when i generate the webservice and let the wsdl/schema be generated,
the common types appear in the correct namespace.
> I would also look into the Axis Helper class generation. As I
> mentioned before the Helper classes are designed so that you don't
> have to write your own implementation of the static method. I would
> check with Axis documentation, it may allow you to have fine grain
> control over the namespaces for a parent and parameter types.
thanx for this hint, i'll try this, too.
> > again the question concerning jaxb 2.0 and annotations like @XmlType:
> > what do you think of this (in relation to beehive)?
> >
>
> At the moment we don't do anything with jaxb. The way I look at it
> is that once the binding libararies (Axis and XMLBeans, etc) supported
> the JaxB, then it would simplify the beehive in the sense that it
> would let the binding libraries and Axis take care of the XML-Java
> configuration. These issues should not really be dealt with in WSM,
> but for now we need to do the work.
alright, i understand.
> Hope it helps
yes, thanx a lot for your help!
the possibility of mixing xmlbeans with pojos allows a really fine
grained control over what will be generated in the wsdl.
thanx again,
cheers,
martin
>
> daryoush
> >
> > > There is no need for the wsdd in what you are trying to do. You just
> > > need to figure out what binding (XML-Java) mechanism you want to use
> > > and implement its requirement.
> > >
> > > > currently, i'm a little bit confused if my aims are kind of strange,
> > > > or if in fact it's the best thing to write schema by hand and
> > > > start from this.
> > > > i really wonder why there's no straight forward way in writing
> > > > webservice in plain old java. aren't annotations the thing that
> > > > would enable us to achieve this?
> > > >
> > > >
> > >
> > > It is a valid expectation to be able to write multiple web services
> > > that are using the same underlying types. There is nothing "strange"
> > > about it, it makes a lot of sense, you would want your types to be the
> > > same when you are moving data around services in SOA.
> > >
> > > In WSM you should be able to do exactly that, and do it all in Java.
> > >
> > > > thanx for your help,
> > > > martin
> > > >
> > > >
> > >
> > > You welcome,
> > >
> > > Daryoush
> > > >
> > > >
> > > >
> > > > On Sun, 2005-08-07 at 11:03 -0700, Daryoush Mehrtash wrote:
> > > > > Martin,
> > > > >
> > > > > Beehive supports three different types in a Web Service.
> > > > >
> > > > > 1. POJO
> > > > > 2. XMLBean types
> > > > > 3. Axis types
> > > > >
> > > > > If you use a POJO as your type, beehive would introspect the class
> > > > > and create its type mappings. It makes your life easier since the
> > > > > introspection walks up the class hierarchy and is smart enough to
> > > > > recognise other Axis or XMLBean types along the way. In this case if
> > > > > you use a same type in two different web services (with different
> > > > > default namespace) you would get different schema. Which is not what
> > > > > you want.
> > > > >
> > > > > The other two alternative (Axis types, and XMLBeans) on the other hand
> > > > > expect the types to do their own serializations. In both of these
> > > > > cases you would be able to get your desired effect, i.e. to reuse the
> > > > > type and still get the same schema.
> > > > >
> > > > > XMLBean types are always generated from schema. They would be an
> > > > > ideal case if you want to start the web service development by
> > > > > defining the schema of the types. You would write your schema and use
> > > > > XMLBean tools to generate the types and then use the types in your web
> > > > > services. You can also take this one step further by using an XML
> > > > > editor to first write the complete WSDL (types, messages, port,
> > > > > binding..) then use beehive to generate your types and the annotated
> > > > > web service class. (see samples/wsm-addressbook-fromWSDL).
> > > > >
> > > > > Your other Alternative is to use Axis types. You would need this if
> > > > > you are using RPC style, or if you want to have fine grain control
> > > > > over the serialization process. You can either write them by hand or
> > > > > use Axis tools to generate the types. This is documented here:
> > > > >
> > > > > http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
> > > > >
> > > > > Note that you would only need the data types that are generated. To
> > > > > write them by hand you would need to implement the three public static
> > > > > methods (getTypeDesc, getSerailizer, and getDeserailizer) for each
> > > > > type. I attached an example for StateType class that was generated
> > > > > by Axis tools, it should give you an idea what you would need to
> > > > > implement. You can drop this class in any JWS, and you should see the
> > > > > type being serialized to http://byXmlBeanNS (just a name i used when i
> > > > > created the type) namespace. Axis also has tools to generate the
> > > > > Helper classes that do serialization (see Axis documentation for more
> > > > > on this).
> > > > >
> > > > > To summarize.... If you are doing RPC style, then use the Axis types
> > > > > (either generated or by hand). If you are using Document style then
> > > > > use XMLBeans if you know the schema of the types, or use Axis types if
> > > > > you want to start from Java and write your own serialization.
> > > > >
> > > > > Hope this helps.
> > > > >
> > > > > Daryoush
> > > > >
> > > > > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > > > hello,
> > > > >
> > > > > what would you think of an additional annotation for the
> > > > > webservice class like @TypeMapping that provides properties
> > > > > like the wsdd-typemapping?
> > > > >
> > > > > i know that this has nothing to do with jsr181 but with axis,
> > > > > but this would be a way to achive more flexibility (concerning
> > > > > things that normally would be done via wsdd)...
> > > > >
> > > > > would this be possible from a technical point of view, and
> > > > > would
> > > > > you integrate things like this into beehive?
> > > > > or what would be the way for customization?
> > > > >
> > > > > cheers,
> > > > > martin
> > > > >
> > > > >
> > > > > On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> > > > > > hello,
> > > > > >
> > > > > > i'm using beehive for writing some webservices, and like it
> > > > > very
> > > > > > much!
> > > > > >
> > > > > > now i want to have a custom type mapping for one class that
> > > > > is used
> > > > > > by more that one webservice in common, but i do not know how
> > > > > to do
> > > > > > this.
> > > > > >
> > > > > > what i have is the following:
> > > > > >
> > > > > > com.comp.ws.WSConsumerInfo
> > > > > > (this is a class that provides information about the
> > > > > webservice
> > > > > > consumer, this is expected by all webservices)
> > > > > >
> > > > > > com.comp.ws.srvc1.WebService1
> > > > > > com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
> > > > > >
> > > > > > com.comp.ws.srvc2.WebService2
> > > > > > com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
> > > > > >
> > > > > > both webservices define their own targetNamespace, e.g.
> > > > > > "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
> > > > > >
> > > > > > when the wsdl for a service is generated, the serializer
> > > > > creates
> > > > > > only the namespace for the service, and the WSConsumerInfo
> > > > > is
> > > > > > created in the same namespace. so, each webservice gets it's
> > > > > own
> > > > > > WSConsumerInfo, what is not desired, because the client's
> > > > > shall
> > > > > > get the WSConsumerInfo as a shared concept, too.
> > > > > > i'd like to have the WSConsumerInfo generated in a common
> > > > > namespace
> > > > > > "http://ws.comp.com".
> > > > > >
> > > > > > is there any way to achieve this with beehive?
> > > > > >
> > > > > > thanx for your help,
> > > > > > cheers,
> > > > > > martin
> > > > > >
> > > > > >
> > > > > --
> > > > > Martin Grotzke
> > > > > Hohenesch 38, 22765 Hamburg
> > > > > Tel. +49 (0) 40.39905668
> > > > > Mobil +49 (0) 170.9365656
> > > > > E-Mail martin.grotzke@javakaffee.de
> > > > > Online http://www.javakaffee.de
> > > > >
> > > > >
> > > > > -----BEGIN PGP SIGNATURE-----
> > > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > > >
> > > > > iD8DBQBC9jSS7FvOl7Te+pYRAuBCAJwPkUSm+dw1h7k
> > > > > ++srrivAfxwIEPACgncgv
> > > > > oVPdxZeypr4wH5Ndf2Yg4FA=
> > > > > =xYUK
> > > > > -----END PGP SIGNATURE-----
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > --
> > > > Martin Grotzke
> > > > Hohenesch 38, 22765 Hamburg
> > > > Tel. +49 (0) 40.39905668
> > > > Mobil +49 (0) 170.9365656
> > > > E-Mail martin.grotzke@javakaffee.de
> > > > Online http://www.javakaffee.de
> > > >
> > > >
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > >
> > > > iD8DBQBC9n837FvOl7Te+pYRAhOcAKCdlYE1ewn/L9m4dc6CL71V4EAu1wCgtK2w
> > > > Dgi0xn1we0VzV8/f7mAdj6c=
> > > > =HzL9
> > > > -----END PGP SIGNATURE-----
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> >
> > iD4DBQBC9yk97FvOl7Te+pYRAvMqAJi+IBLTqsOhvwj9EgO8M1LhLgw9AJ9VS6WT
> > I/5LW6cKclb+TtAlPBesFw==
> > =ZC3r
> > -----END PGP SIGNATURE-----
> >
> >
> >
>
>
>
--
Martin Grotzke
Hohenesch 38, 22765 Hamburg
Tel. +49 (0) 40.39905668
Mobil +49 (0) 170.9365656
E-Mail martin.grotzke@javakaffee.de
Online http://www.javakaffee.de
Re: wsdl/schema generation and custom type mapping
Posted by Daryoush Mehrtash <dm...@gmail.com>.
Comments below
On 8/8/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> hello,
>
> On Sun, 2005-08-07 at 22:58 -0700, Daryoush Mehrtash wrote:
> > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > or would it be possible to define the common types with a schema,
> > > generate the java classes, and write the other domain objects directly
> > > in java?
> > >
> >
> > When you have a
> >
> > @WebMethod doFooBar(X x, Y y, Z z)
> >
> > You can mix and match the type. For example X could be a POJO, Y
> > could be XMLBean and Z could be Axis type. Furthermore, the X (POJO)
> > could be simple java class with simple types, a java class that
> > inherits from a base class, or a java class that contains other Axis
> > or XMLBean types.
> alright, great.
>
> > > what is the difference to implementing the getTypeDesc, getSerializer
> > > and getDeserializer for these common types?
> >
> > I am not sure I understand the question here, these methods are what
> > Axis Binding would need.
>
> sorry, somewhat unclear, i was referring to what i described below.
> following a hopefully more comprehensive description...
>
> i have s.th. like the following:
>
> package com.comp.ws.srvc1;
> @WebService(targetNamespace="srvc1.ws.comp.com")
> class WebService1 {
> @WebMethod void doFoo( WS1Request req ){}
> }
>
> package com.comp.ws.srvc2;
> @WebService(targetNamespace="srvc2.ws.comp.com")
> class WebService2 {
> @WebMethod void doBar( WS2Request req ){}
> }
>
> where both WS1Request and WS2Request have their domain properties and
> associate an instance of the class
> com.comp.ws.WSConsumerInfo.
> WSConsumerInfo is a technically motivated class that is written once
> and used for all webservice invokations.
>
> the problem now was, that i implemented the getTypeDesc (with namespace
> "ws.comp.com"), getSerializer and getDeserializer for the
> WSConsumerInfo, but that this was not enough to get the schema for this
> class generated in the "ws.comp.com" namespace.
> to achive this, i had to implement the getTypeDesc etc. in WS1Request
> and WS2Request, with the _complete_ type description for these classes,
> with all their properties, that i don't want to customize.
>
> i don't understand why i have to write type descriptions for classes
> that i do not want to customize, why it's not enough to provide this
> information in the WSConsumerInfo - but this is probably an axis-thing.
>
So you have two classes WS1Request and WS2Request, both of which are
sub class of WSConsumerInfo and you want to have WSConsumerInfo to
have common namespace in both web services. Right? If so, I
haven't tried this, we would have to do some experiment on this.
If you want to use POJOs as your types, my initial suggestion would be
to put all your types in same namespace regardless of the web service
namespace. You can use @WebParam to configure the namespace of the
parameters. This way the base class and the derived classes would end
up on the same namespace. Would that work for you?
>
> to get back to the question (the difference between the xmlbeans and
> the axis type approach): i wanted to know, if it would be enough to
> define the xml schema for WSConsumerInfo, and write the WS*Request
> as clean POJO, with the result that i get the WS*Request in the
> namespace "srvc*.ws.comp.com", referencing the WSConsumerInfo in it's
> "ws.comp.com" namespace.
>
I haven't tried this to give you a definitive answer. Thinking about
it though, it may work. Can you run some some experiment on this and
let us know. I would think if the WS*Request had WSConsumerInfo as a
member variable it would be more likely that it would work. If the
WS*Request classes are subclass of WSCOnsumerInfo it may still work,
but I am less confident.
I would also look into the Axis Helper class generation. As I
mentioned before the Helper classes are designed so that you don't
have to write your own implementation of the static method. I would
check with Axis documentation, it may allow you to have fine grain
control over the namespaces for a parent and parameter types.
> i hope this makes it more clear :)
>
> btw. you're right, i have document/wrapped style.
>
In this case define all your types as XMLBeans, starting from schema.
You would be able to place any piece of the types in any namespace you
choose and use the generated types in your services as you wish.
> again the question concerning jaxb 2.0 and annotations like @XmlType:
> what do you think of this (in relation to beehive)?
>
At the moment we don't do anything with jaxb. The way I look at it
is that once the binding libararies (Axis and XMLBeans, etc) supported
the JaxB, then it would simplify the beehive in the sense that it
would let the binding libraries and Axis take care of the XML-Java
configuration. These issues should not really be dealt with in WSM,
but for now we need to do the work. To answer your question... I
don't know of any plan to support @XmlType, but on the look out for
implementation of the JaxB to integrate with WSM :)
>
> thanx & cheers,
> martin
>
Hope it helps
daryoush
>
> > There is no need for the wsdd in what you are trying to do. You just
> > need to figure out what binding (XML-Java) mechanism you want to use
> > and implement its requirement.
> >
> > > currently, i'm a little bit confused if my aims are kind of strange,
> > > or if in fact it's the best thing to write schema by hand and
> > > start from this.
> > > i really wonder why there's no straight forward way in writing
> > > webservice in plain old java. aren't annotations the thing that
> > > would enable us to achieve this?
> > >
> > >
> >
> > It is a valid expectation to be able to write multiple web services
> > that are using the same underlying types. There is nothing "strange"
> > about it, it makes a lot of sense, you would want your types to be the
> > same when you are moving data around services in SOA.
> >
> > In WSM you should be able to do exactly that, and do it all in Java.
> >
> > > thanx for your help,
> > > martin
> > >
> > >
> >
> > You welcome,
> >
> > Daryoush
> > >
> > >
> > >
> > > On Sun, 2005-08-07 at 11:03 -0700, Daryoush Mehrtash wrote:
> > > > Martin,
> > > >
> > > > Beehive supports three different types in a Web Service.
> > > >
> > > > 1. POJO
> > > > 2. XMLBean types
> > > > 3. Axis types
> > > >
> > > > If you use a POJO as your type, beehive would introspect the class
> > > > and create its type mappings. It makes your life easier since the
> > > > introspection walks up the class hierarchy and is smart enough to
> > > > recognise other Axis or XMLBean types along the way. In this case if
> > > > you use a same type in two different web services (with different
> > > > default namespace) you would get different schema. Which is not what
> > > > you want.
> > > >
> > > > The other two alternative (Axis types, and XMLBeans) on the other hand
> > > > expect the types to do their own serializations. In both of these
> > > > cases you would be able to get your desired effect, i.e. to reuse the
> > > > type and still get the same schema.
> > > >
> > > > XMLBean types are always generated from schema. They would be an
> > > > ideal case if you want to start the web service development by
> > > > defining the schema of the types. You would write your schema and use
> > > > XMLBean tools to generate the types and then use the types in your web
> > > > services. You can also take this one step further by using an XML
> > > > editor to first write the complete WSDL (types, messages, port,
> > > > binding..) then use beehive to generate your types and the annotated
> > > > web service class. (see samples/wsm-addressbook-fromWSDL).
> > > >
> > > > Your other Alternative is to use Axis types. You would need this if
> > > > you are using RPC style, or if you want to have fine grain control
> > > > over the serialization process. You can either write them by hand or
> > > > use Axis tools to generate the types. This is documented here:
> > > >
> > > > http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
> > > >
> > > > Note that you would only need the data types that are generated. To
> > > > write them by hand you would need to implement the three public static
> > > > methods (getTypeDesc, getSerailizer, and getDeserailizer) for each
> > > > type. I attached an example for StateType class that was generated
> > > > by Axis tools, it should give you an idea what you would need to
> > > > implement. You can drop this class in any JWS, and you should see the
> > > > type being serialized to http://byXmlBeanNS (just a name i used when i
> > > > created the type) namespace. Axis also has tools to generate the
> > > > Helper classes that do serialization (see Axis documentation for more
> > > > on this).
> > > >
> > > > To summarize.... If you are doing RPC style, then use the Axis types
> > > > (either generated or by hand). If you are using Document style then
> > > > use XMLBeans if you know the schema of the types, or use Axis types if
> > > > you want to start from Java and write your own serialization.
> > > >
> > > > Hope this helps.
> > > >
> > > > Daryoush
> > > >
> > > > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > > hello,
> > > >
> > > > what would you think of an additional annotation for the
> > > > webservice class like @TypeMapping that provides properties
> > > > like the wsdd-typemapping?
> > > >
> > > > i know that this has nothing to do with jsr181 but with axis,
> > > > but this would be a way to achive more flexibility (concerning
> > > > things that normally would be done via wsdd)...
> > > >
> > > > would this be possible from a technical point of view, and
> > > > would
> > > > you integrate things like this into beehive?
> > > > or what would be the way for customization?
> > > >
> > > > cheers,
> > > > martin
> > > >
> > > >
> > > > On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> > > > > hello,
> > > > >
> > > > > i'm using beehive for writing some webservices, and like it
> > > > very
> > > > > much!
> > > > >
> > > > > now i want to have a custom type mapping for one class that
> > > > is used
> > > > > by more that one webservice in common, but i do not know how
> > > > to do
> > > > > this.
> > > > >
> > > > > what i have is the following:
> > > > >
> > > > > com.comp.ws.WSConsumerInfo
> > > > > (this is a class that provides information about the
> > > > webservice
> > > > > consumer, this is expected by all webservices)
> > > > >
> > > > > com.comp.ws.srvc1.WebService1
> > > > > com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
> > > > >
> > > > > com.comp.ws.srvc2.WebService2
> > > > > com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
> > > > >
> > > > > both webservices define their own targetNamespace, e.g.
> > > > > "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
> > > > >
> > > > > when the wsdl for a service is generated, the serializer
> > > > creates
> > > > > only the namespace for the service, and the WSConsumerInfo
> > > > is
> > > > > created in the same namespace. so, each webservice gets it's
> > > > own
> > > > > WSConsumerInfo, what is not desired, because the client's
> > > > shall
> > > > > get the WSConsumerInfo as a shared concept, too.
> > > > > i'd like to have the WSConsumerInfo generated in a common
> > > > namespace
> > > > > "http://ws.comp.com".
> > > > >
> > > > > is there any way to achieve this with beehive?
> > > > >
> > > > > thanx for your help,
> > > > > cheers,
> > > > > martin
> > > > >
> > > > >
> > > > --
> > > > Martin Grotzke
> > > > Hohenesch 38, 22765 Hamburg
> > > > Tel. +49 (0) 40.39905668
> > > > Mobil +49 (0) 170.9365656
> > > > E-Mail martin.grotzke@javakaffee.de
> > > > Online http://www.javakaffee.de
> > > >
> > > >
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > >
> > > > iD8DBQBC9jSS7FvOl7Te+pYRAuBCAJwPkUSm+dw1h7k
> > > > ++srrivAfxwIEPACgncgv
> > > > oVPdxZeypr4wH5Ndf2Yg4FA=
> > > > =xYUK
> > > > -----END PGP SIGNATURE-----
> > > >
> > > >
> > > >
> > > >
> > > >
> > > --
> > > Martin Grotzke
> > > Hohenesch 38, 22765 Hamburg
> > > Tel. +49 (0) 40.39905668
> > > Mobil +49 (0) 170.9365656
> > > E-Mail martin.grotzke@javakaffee.de
> > > Online http://www.javakaffee.de
> > >
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.1 (GNU/Linux)
> > >
> > > iD8DBQBC9n837FvOl7Te+pYRAhOcAKCdlYE1ewn/L9m4dc6CL71V4EAu1wCgtK2w
> > > Dgi0xn1we0VzV8/f7mAdj6c=
> > > =HzL9
> > > -----END PGP SIGNATURE-----
> > >
> > >
> > >
> >
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD4DBQBC9yk97FvOl7Te+pYRAvMqAJi+IBLTqsOhvwj9EgO8M1LhLgw9AJ9VS6WT
> I/5LW6cKclb+TtAlPBesFw==
> =ZC3r
> -----END PGP SIGNATURE-----
>
>
>
--
Daryoush
Weblog: http://perlustration.blogspot.com/
Re: wsdl/schema generation and custom type mapping
Posted by Martin Grotzke <ma...@javakaffee.de>.
hello,
On Sun, 2005-08-07 at 22:58 -0700, Daryoush Mehrtash wrote:
> On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > or would it be possible to define the common types with a schema,
> > generate the java classes, and write the other domain objects directly
> > in java?
> >
>
> When you have a
>
> @WebMethod doFooBar(X x, Y y, Z z)
>
> You can mix and match the type. For example X could be a POJO, Y
> could be XMLBean and Z could be Axis type. Furthermore, the X (POJO)
> could be simple java class with simple types, a java class that
> inherits from a base class, or a java class that contains other Axis
> or XMLBean types.
alright, great.
> > what is the difference to implementing the getTypeDesc, getSerializer
> > and getDeserializer for these common types?
>
> I am not sure I understand the question here, these methods are what
> Axis Binding would need.
sorry, somewhat unclear, i was referring to what i described below.
following a hopefully more comprehensive description...
i have s.th. like the following:
package com.comp.ws.srvc1;
@WebService(targetNamespace="srvc1.ws.comp.com")
class WebService1 {
@WebMethod void doFoo( WS1Request req ){}
}
package com.comp.ws.srvc2;
@WebService(targetNamespace="srvc2.ws.comp.com")
class WebService2 {
@WebMethod void doBar( WS2Request req ){}
}
where both WS1Request and WS2Request have their domain properties and
associate an instance of the class
com.comp.ws.WSConsumerInfo.
WSConsumerInfo is a technically motivated class that is written once
and used for all webservice invokations.
the problem now was, that i implemented the getTypeDesc (with namespace
"ws.comp.com"), getSerializer and getDeserializer for the
WSConsumerInfo, but that this was not enough to get the schema for this
class generated in the "ws.comp.com" namespace.
to achive this, i had to implement the getTypeDesc etc. in WS1Request
and WS2Request, with the _complete_ type description for these classes,
with all their properties, that i don't want to customize.
i don't understand why i have to write type descriptions for classes
that i do not want to customize, why it's not enough to provide this
information in the WSConsumerInfo - but this is probably an axis-thing.
to get back to the question (the difference between the xmlbeans and
the axis type approach): i wanted to know, if it would be enough to
define the xml schema for WSConsumerInfo, and write the WS*Request
as clean POJO, with the result that i get the WS*Request in the
namespace "srvc*.ws.comp.com", referencing the WSConsumerInfo in it's
"ws.comp.com" namespace.
i hope this makes it more clear :)
btw. you're right, i have document/wrapped style.
again the question concerning jaxb 2.0 and annotations like @XmlType:
what do you think of this (in relation to beehive)?
thanx & cheers,
martin
> There is no need for the wsdd in what you are trying to do. You just
> need to figure out what binding (XML-Java) mechanism you want to use
> and implement its requirement.
>
> > currently, i'm a little bit confused if my aims are kind of strange,
> > or if in fact it's the best thing to write schema by hand and
> > start from this.
> > i really wonder why there's no straight forward way in writing
> > webservice in plain old java. aren't annotations the thing that
> > would enable us to achieve this?
> >
> >
>
> It is a valid expectation to be able to write multiple web services
> that are using the same underlying types. There is nothing "strange"
> about it, it makes a lot of sense, you would want your types to be the
> same when you are moving data around services in SOA.
>
> In WSM you should be able to do exactly that, and do it all in Java.
>
> > thanx for your help,
> > martin
> >
> >
>
> You welcome,
>
> Daryoush
> >
> >
> >
> > On Sun, 2005-08-07 at 11:03 -0700, Daryoush Mehrtash wrote:
> > > Martin,
> > >
> > > Beehive supports three different types in a Web Service.
> > >
> > > 1. POJO
> > > 2. XMLBean types
> > > 3. Axis types
> > >
> > > If you use a POJO as your type, beehive would introspect the class
> > > and create its type mappings. It makes your life easier since the
> > > introspection walks up the class hierarchy and is smart enough to
> > > recognise other Axis or XMLBean types along the way. In this case if
> > > you use a same type in two different web services (with different
> > > default namespace) you would get different schema. Which is not what
> > > you want.
> > >
> > > The other two alternative (Axis types, and XMLBeans) on the other hand
> > > expect the types to do their own serializations. In both of these
> > > cases you would be able to get your desired effect, i.e. to reuse the
> > > type and still get the same schema.
> > >
> > > XMLBean types are always generated from schema. They would be an
> > > ideal case if you want to start the web service development by
> > > defining the schema of the types. You would write your schema and use
> > > XMLBean tools to generate the types and then use the types in your web
> > > services. You can also take this one step further by using an XML
> > > editor to first write the complete WSDL (types, messages, port,
> > > binding..) then use beehive to generate your types and the annotated
> > > web service class. (see samples/wsm-addressbook-fromWSDL).
> > >
> > > Your other Alternative is to use Axis types. You would need this if
> > > you are using RPC style, or if you want to have fine grain control
> > > over the serialization process. You can either write them by hand or
> > > use Axis tools to generate the types. This is documented here:
> > >
> > > http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
> > >
> > > Note that you would only need the data types that are generated. To
> > > write them by hand you would need to implement the three public static
> > > methods (getTypeDesc, getSerailizer, and getDeserailizer) for each
> > > type. I attached an example for StateType class that was generated
> > > by Axis tools, it should give you an idea what you would need to
> > > implement. You can drop this class in any JWS, and you should see the
> > > type being serialized to http://byXmlBeanNS (just a name i used when i
> > > created the type) namespace. Axis also has tools to generate the
> > > Helper classes that do serialization (see Axis documentation for more
> > > on this).
> > >
> > > To summarize.... If you are doing RPC style, then use the Axis types
> > > (either generated or by hand). If you are using Document style then
> > > use XMLBeans if you know the schema of the types, or use Axis types if
> > > you want to start from Java and write your own serialization.
> > >
> > > Hope this helps.
> > >
> > > Daryoush
> > >
> > > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > > hello,
> > >
> > > what would you think of an additional annotation for the
> > > webservice class like @TypeMapping that provides properties
> > > like the wsdd-typemapping?
> > >
> > > i know that this has nothing to do with jsr181 but with axis,
> > > but this would be a way to achive more flexibility (concerning
> > > things that normally would be done via wsdd)...
> > >
> > > would this be possible from a technical point of view, and
> > > would
> > > you integrate things like this into beehive?
> > > or what would be the way for customization?
> > >
> > > cheers,
> > > martin
> > >
> > >
> > > On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> > > > hello,
> > > >
> > > > i'm using beehive for writing some webservices, and like it
> > > very
> > > > much!
> > > >
> > > > now i want to have a custom type mapping for one class that
> > > is used
> > > > by more that one webservice in common, but i do not know how
> > > to do
> > > > this.
> > > >
> > > > what i have is the following:
> > > >
> > > > com.comp.ws.WSConsumerInfo
> > > > (this is a class that provides information about the
> > > webservice
> > > > consumer, this is expected by all webservices)
> > > >
> > > > com.comp.ws.srvc1.WebService1
> > > > com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
> > > >
> > > > com.comp.ws.srvc2.WebService2
> > > > com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
> > > >
> > > > both webservices define their own targetNamespace, e.g.
> > > > "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
> > > >
> > > > when the wsdl for a service is generated, the serializer
> > > creates
> > > > only the namespace for the service, and the WSConsumerInfo
> > > is
> > > > created in the same namespace. so, each webservice gets it's
> > > own
> > > > WSConsumerInfo, what is not desired, because the client's
> > > shall
> > > > get the WSConsumerInfo as a shared concept, too.
> > > > i'd like to have the WSConsumerInfo generated in a common
> > > namespace
> > > > "http://ws.comp.com".
> > > >
> > > > is there any way to achieve this with beehive?
> > > >
> > > > thanx for your help,
> > > > cheers,
> > > > martin
> > > >
> > > >
> > > --
> > > Martin Grotzke
> > > Hohenesch 38, 22765 Hamburg
> > > Tel. +49 (0) 40.39905668
> > > Mobil +49 (0) 170.9365656
> > > E-Mail martin.grotzke@javakaffee.de
> > > Online http://www.javakaffee.de
> > >
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.1 (GNU/Linux)
> > >
> > > iD8DBQBC9jSS7FvOl7Te+pYRAuBCAJwPkUSm+dw1h7k
> > > ++srrivAfxwIEPACgncgv
> > > oVPdxZeypr4wH5Ndf2Yg4FA=
> > > =xYUK
> > > -----END PGP SIGNATURE-----
> > >
> > >
> > >
> > >
> > >
> > --
> > Martin Grotzke
> > Hohenesch 38, 22765 Hamburg
> > Tel. +49 (0) 40.39905668
> > Mobil +49 (0) 170.9365656
> > E-Mail martin.grotzke@javakaffee.de
> > Online http://www.javakaffee.de
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> >
> > iD8DBQBC9n837FvOl7Te+pYRAhOcAKCdlYE1ewn/L9m4dc6CL71V4EAu1wCgtK2w
> > Dgi0xn1we0VzV8/f7mAdj6c=
> > =HzL9
> > -----END PGP SIGNATURE-----
> >
> >
> >
>
Re: wsdl/schema generation and custom type mapping
Posted by Daryoush Mehrtash <dm...@gmail.com>.
Comments below
On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> daryoush,
>
> thank you for your great and extensive answer!
>
> if i understand the xmlbeans way correctly, i would have to define
> all of the types with a schema?
> or would it be possible to define the common types with a schema,
> generate the java classes, and write the other domain objects directly
> in java?
>
When you have a
@WebMethod doFooBar(X x, Y y, Z z)
You can mix and match the type. For example X could be a POJO, Y
could be XMLBean and Z could be Axis type. Furthermore, the X (POJO)
could be simple java class with simple types, a java class that
inherits from a base class, or a java class that contains other Axis
or XMLBean types.
If you want to use an XMLBean type (for example Y) then you would have
to first write its schema, then generate the type. Lets say your
company defines a PurchseOrder schema, you can use the schema to
generate the types and then write your methods.
> what is the difference to implementing the getTypeDesc, getSerializer
> and getDeserializer for these common types?
I am not sure I understand the question here, these methods are what
Axis Binding would need. You have three choise with Axis types:
1) write the schema for types (similar to XMLBeans) and generate the type
2) write a POJO class them add the methods that would take care of the
serialization
3) use Axis tool to generate Helper class for the POJO of your type.
see Axis documentation for 2, 3.
If your intention is to use Document type, I would recommend that you
start from a schema and go the XMLBean route. Compare to a Java
class, Schema would give you a lot more power in defining a precise
service.
>
> btw: i yet tried to implement these three static methods for the
> common types, but noticed that this is not enough.
> i had to implement these methods in the referencing types
> (in the given example, i had to specify the XmlType with the custom
> namespace for WSConsumerInfo in the referencing MyWS1Request
> and MyWS2Request) to get the common type in the correct namespace
> generated.
> but this means, that i have to write serialization information for each
> request object, so i could even write the schema by hand.
>
Let me make sure we are talking about the same thing here... Let say
I have two Document/Wrapped web services (in different namespaces)
that share a type (e.g. MyType in typeNamespace)
WebService1 in namespace: webService_1_namespace
@WebMethod doFoo(MyType type)
WebService2 in namespace: webService_2_namespace
@WebMethod doBar(MyType type)
then in this case the WSDL for both web services would have a schema
section for typeNamespace that describe the MyType. The
WebService1's WSDL would also have a schema for doFoo, and
doFooResponse (in webService_1_namespace) and WebService2's WSDL would
have schema for doBar and doBarResponse in webService_2_namespace.
So the types for both service would be in their own namespaces but the
methods would be on the namespace of the webservice.
I am not sure if this answers your question or not. If not may be it
would be better if you can send a simple example to go over it.
> i thought the basic approach of beehive (or annotations more
> generically) is to have only one artifact that is edited by
> the developer.
> so would expect to do as much as possible in java what otherwise
> would have been done in several files (deployment descriptors like
> wsdd).
>
There is no need for the wsdd in what you are trying to do. You just
need to figure out what binding (XML-Java) mechanism you want to use
and implement its requirement.
> currently, i'm a little bit confused if my aims are kind of strange,
> or if in fact it's the best thing to write schema by hand and
> start from this.
> i really wonder why there's no straight forward way in writing
> webservice in plain old java. aren't annotations the thing that
> would enable us to achieve this?
>
>
It is a valid expectation to be able to write multiple web services
that are using the same underlying types. There is nothing "strange"
about it, it makes a lot of sense, you would want your types to be the
same when you are moving data around services in SOA.
In WSM you should be able to do exactly that, and do it all in Java.
> thanx for your help,
> martin
>
>
You welcome,
Daryoush
>
>
>
> On Sun, 2005-08-07 at 11:03 -0700, Daryoush Mehrtash wrote:
> > Martin,
> >
> > Beehive supports three different types in a Web Service.
> >
> > 1. POJO
> > 2. XMLBean types
> > 3. Axis types
> >
> > If you use a POJO as your type, beehive would introspect the class
> > and create its type mappings. It makes your life easier since the
> > introspection walks up the class hierarchy and is smart enough to
> > recognise other Axis or XMLBean types along the way. In this case if
> > you use a same type in two different web services (with different
> > default namespace) you would get different schema. Which is not what
> > you want.
> >
> > The other two alternative (Axis types, and XMLBeans) on the other hand
> > expect the types to do their own serializations. In both of these
> > cases you would be able to get your desired effect, i.e. to reuse the
> > type and still get the same schema.
> >
> > XMLBean types are always generated from schema. They would be an
> > ideal case if you want to start the web service development by
> > defining the schema of the types. You would write your schema and use
> > XMLBean tools to generate the types and then use the types in your web
> > services. You can also take this one step further by using an XML
> > editor to first write the complete WSDL (types, messages, port,
> > binding..) then use beehive to generate your types and the annotated
> > web service class. (see samples/wsm-addressbook-fromWSDL).
> >
> > Your other Alternative is to use Axis types. You would need this if
> > you are using RPC style, or if you want to have fine grain control
> > over the serialization process. You can either write them by hand or
> > use Axis tools to generate the types. This is documented here:
> >
> > http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
> >
> > Note that you would only need the data types that are generated. To
> > write them by hand you would need to implement the three public static
> > methods (getTypeDesc, getSerailizer, and getDeserailizer) for each
> > type. I attached an example for StateType class that was generated
> > by Axis tools, it should give you an idea what you would need to
> > implement. You can drop this class in any JWS, and you should see the
> > type being serialized to http://byXmlBeanNS (just a name i used when i
> > created the type) namespace. Axis also has tools to generate the
> > Helper classes that do serialization (see Axis documentation for more
> > on this).
> >
> > To summarize.... If you are doing RPC style, then use the Axis types
> > (either generated or by hand). If you are using Document style then
> > use XMLBeans if you know the schema of the types, or use Axis types if
> > you want to start from Java and write your own serialization.
> >
> > Hope this helps.
> >
> > Daryoush
> >
> > On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> > hello,
> >
> > what would you think of an additional annotation for the
> > webservice class like @TypeMapping that provides properties
> > like the wsdd-typemapping?
> >
> > i know that this has nothing to do with jsr181 but with axis,
> > but this would be a way to achive more flexibility (concerning
> > things that normally would be done via wsdd)...
> >
> > would this be possible from a technical point of view, and
> > would
> > you integrate things like this into beehive?
> > or what would be the way for customization?
> >
> > cheers,
> > martin
> >
> >
> > On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> > > hello,
> > >
> > > i'm using beehive for writing some webservices, and like it
> > very
> > > much!
> > >
> > > now i want to have a custom type mapping for one class that
> > is used
> > > by more that one webservice in common, but i do not know how
> > to do
> > > this.
> > >
> > > what i have is the following:
> > >
> > > com.comp.ws.WSConsumerInfo
> > > (this is a class that provides information about the
> > webservice
> > > consumer, this is expected by all webservices)
> > >
> > > com.comp.ws.srvc1.WebService1
> > > com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
> > >
> > > com.comp.ws.srvc2.WebService2
> > > com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
> > >
> > > both webservices define their own targetNamespace, e.g.
> > > "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
> > >
> > > when the wsdl for a service is generated, the serializer
> > creates
> > > only the namespace for the service, and the WSConsumerInfo
> > is
> > > created in the same namespace. so, each webservice gets it's
> > own
> > > WSConsumerInfo, what is not desired, because the client's
> > shall
> > > get the WSConsumerInfo as a shared concept, too.
> > > i'd like to have the WSConsumerInfo generated in a common
> > namespace
> > > "http://ws.comp.com".
> > >
> > > is there any way to achieve this with beehive?
> > >
> > > thanx for your help,
> > > cheers,
> > > martin
> > >
> > >
> > --
> > Martin Grotzke
> > Hohenesch 38, 22765 Hamburg
> > Tel. +49 (0) 40.39905668
> > Mobil +49 (0) 170.9365656
> > E-Mail martin.grotzke@javakaffee.de
> > Online http://www.javakaffee.de
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> >
> > iD8DBQBC9jSS7FvOl7Te+pYRAuBCAJwPkUSm+dw1h7k
> > ++srrivAfxwIEPACgncgv
> > oVPdxZeypr4wH5Ndf2Yg4FA=
> > =xYUK
> > -----END PGP SIGNATURE-----
> >
> >
> >
> >
> >
> --
> Martin Grotzke
> Hohenesch 38, 22765 Hamburg
> Tel. +49 (0) 40.39905668
> Mobil +49 (0) 170.9365656
> E-Mail martin.grotzke@javakaffee.de
> Online http://www.javakaffee.de
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBC9n837FvOl7Te+pYRAhOcAKCdlYE1ewn/L9m4dc6CL71V4EAu1wCgtK2w
> Dgi0xn1we0VzV8/f7mAdj6c=
> =HzL9
> -----END PGP SIGNATURE-----
>
>
>
--
Daryoush
Weblog: http://perlustration.blogspot.com/
Re: wsdl/schema generation and custom type mapping
Posted by Martin Grotzke <ma...@javakaffee.de>.
daryoush,
thank you for your great and extensive answer!
if i understand the xmlbeans way correctly, i would have to define
all of the types with a schema?
or would it be possible to define the common types with a schema,
generate the java classes, and write the other domain objects directly
in java?
what is the difference to implementing the getTypeDesc, getSerializer
and getDeserializer for these common types?
btw: i yet tried to implement these three static methods for the
common types, but noticed that this is not enough.
i had to implement these methods in the referencing types
(in the given example, i had to specify the XmlType with the custom
namespace for WSConsumerInfo in the referencing MyWS1Request
and MyWS2Request) to get the common type in the correct namespace
generated.
but this means, that i have to write serialization information for each
request object, so i could even write the schema by hand.
i thought the basic approach of beehive (or annotations more
generically) is to have only one artifact that is edited by
the developer.
so would expect to do as much as possible in java what otherwise
would have been done in several files (deployment descriptors like
wsdd).
currently, i'm a little bit confused if my aims are kind of strange,
or if in fact it's the best thing to write schema by hand and
start from this.
i really wonder why there's no straight forward way in writing
webservice in plain old java. aren't annotations the thing that
would enable us to achieve this?
thanx for your help,
martin
On Sun, 2005-08-07 at 11:03 -0700, Daryoush Mehrtash wrote:
> Martin,
>
> Beehive supports three different types in a Web Service.
>
> 1. POJO
> 2. XMLBean types
> 3. Axis types
>
> If you use a POJO as your type, beehive would introspect the class
> and create its type mappings. It makes your life easier since the
> introspection walks up the class hierarchy and is smart enough to
> recognise other Axis or XMLBean types along the way. In this case if
> you use a same type in two different web services (with different
> default namespace) you would get different schema. Which is not what
> you want.
>
> The other two alternative (Axis types, and XMLBeans) on the other hand
> expect the types to do their own serializations. In both of these
> cases you would be able to get your desired effect, i.e. to reuse the
> type and still get the same schema.
>
> XMLBean types are always generated from schema. They would be an
> ideal case if you want to start the web service development by
> defining the schema of the types. You would write your schema and use
> XMLBean tools to generate the types and then use the types in your web
> services. You can also take this one step further by using an XML
> editor to first write the complete WSDL (types, messages, port,
> binding..) then use beehive to generate your types and the annotated
> web service class. (see samples/wsm-addressbook-fromWSDL).
>
> Your other Alternative is to use Axis types. You would need this if
> you are using RPC style, or if you want to have fine grain control
> over the serialization process. You can either write them by hand or
> use Axis tools to generate the types. This is documented here:
>
> http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
>
> Note that you would only need the data types that are generated. To
> write them by hand you would need to implement the three public static
> methods (getTypeDesc, getSerailizer, and getDeserailizer) for each
> type. I attached an example for StateType class that was generated
> by Axis tools, it should give you an idea what you would need to
> implement. You can drop this class in any JWS, and you should see the
> type being serialized to http://byXmlBeanNS (just a name i used when i
> created the type) namespace. Axis also has tools to generate the
> Helper classes that do serialization (see Axis documentation for more
> on this).
>
> To summarize.... If you are doing RPC style, then use the Axis types
> (either generated or by hand). If you are using Document style then
> use XMLBeans if you know the schema of the types, or use Axis types if
> you want to start from Java and write your own serialization.
>
> Hope this helps.
>
> Daryoush
>
> On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> hello,
>
> what would you think of an additional annotation for the
> webservice class like @TypeMapping that provides properties
> like the wsdd-typemapping?
>
> i know that this has nothing to do with jsr181 but with axis,
> but this would be a way to achive more flexibility (concerning
> things that normally would be done via wsdd)...
>
> would this be possible from a technical point of view, and
> would
> you integrate things like this into beehive?
> or what would be the way for customization?
>
> cheers,
> martin
>
>
> On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> > hello,
> >
> > i'm using beehive for writing some webservices, and like it
> very
> > much!
> >
> > now i want to have a custom type mapping for one class that
> is used
> > by more that one webservice in common, but i do not know how
> to do
> > this.
> >
> > what i have is the following:
> >
> > com.comp.ws.WSConsumerInfo
> > (this is a class that provides information about the
> webservice
> > consumer, this is expected by all webservices)
> >
> > com.comp.ws.srvc1.WebService1
> > com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
> >
> > com.comp.ws.srvc2.WebService2
> > com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
> >
> > both webservices define their own targetNamespace, e.g.
> > "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
> >
> > when the wsdl for a service is generated, the serializer
> creates
> > only the namespace for the service, and the WSConsumerInfo
> is
> > created in the same namespace. so, each webservice gets it's
> own
> > WSConsumerInfo, what is not desired, because the client's
> shall
> > get the WSConsumerInfo as a shared concept, too.
> > i'd like to have the WSConsumerInfo generated in a common
> namespace
> > "http://ws.comp.com".
> >
> > is there any way to achieve this with beehive?
> >
> > thanx for your help,
> > cheers,
> > martin
> >
> >
> --
> Martin Grotzke
> Hohenesch 38, 22765 Hamburg
> Tel. +49 (0) 40.39905668
> Mobil +49 (0) 170.9365656
> E-Mail martin.grotzke@javakaffee.de
> Online http://www.javakaffee.de
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBC9jSS7FvOl7Te+pYRAuBCAJwPkUSm+dw1h7k
> ++srrivAfxwIEPACgncgv
> oVPdxZeypr4wH5Ndf2Yg4FA=
> =xYUK
> -----END PGP SIGNATURE-----
>
>
>
>
>
--
Martin Grotzke
Hohenesch 38, 22765 Hamburg
Tel. +49 (0) 40.39905668
Mobil +49 (0) 170.9365656
E-Mail martin.grotzke@javakaffee.de
Online http://www.javakaffee.de
Re: wsdl/schema generation and custom type mapping
Posted by Martin Grotzke <ma...@javakaffee.de>.
hi,
i just found that jaxb-2.0 provides what i'm looking for, e.g.:
https://jaxb.dev.java.net/nonav/jaxb20-pr/api/javax/xml/bind/annotation/XmlType.html
wouldn't it be cool to have this in beehive? or doesn't that
fit into the concepts behind beehive?
cheers,
martin
On Sun, 2005-08-07 at 11:03 -0700, Daryoush Mehrtash wrote:
> Martin,
>
> Beehive supports three different types in a Web Service.
>
> 1. POJO
> 2. XMLBean types
> 3. Axis types
>
> If you use a POJO as your type, beehive would introspect the class
> and create its type mappings. It makes your life easier since the
> introspection walks up the class hierarchy and is smart enough to
> recognise other Axis or XMLBean types along the way. In this case if
> you use a same type in two different web services (with different
> default namespace) you would get different schema. Which is not what
> you want.
>
> The other two alternative (Axis types, and XMLBeans) on the other hand
> expect the types to do their own serializations. In both of these
> cases you would be able to get your desired effect, i.e. to reuse the
> type and still get the same schema.
>
> XMLBean types are always generated from schema. They would be an
> ideal case if you want to start the web service development by
> defining the schema of the types. You would write your schema and use
> XMLBean tools to generate the types and then use the types in your web
> services. You can also take this one step further by using an XML
> editor to first write the complete WSDL (types, messages, port,
> binding..) then use beehive to generate your types and the annotated
> web service class. (see samples/wsm-addressbook-fromWSDL).
>
> Your other Alternative is to use Axis types. You would need this if
> you are using RPC style, or if you want to have fine grain control
> over the serialization process. You can either write them by hand or
> use Axis tools to generate the types. This is documented here:
>
> http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
>
> Note that you would only need the data types that are generated. To
> write them by hand you would need to implement the three public static
> methods (getTypeDesc, getSerailizer, and getDeserailizer) for each
> type. I attached an example for StateType class that was generated
> by Axis tools, it should give you an idea what you would need to
> implement. You can drop this class in any JWS, and you should see the
> type being serialized to http://byXmlBeanNS (just a name i used when i
> created the type) namespace. Axis also has tools to generate the
> Helper classes that do serialization (see Axis documentation for more
> on this).
>
> To summarize.... If you are doing RPC style, then use the Axis types
> (either generated or by hand). If you are using Document style then
> use XMLBeans if you know the schema of the types, or use Axis types if
> you want to start from Java and write your own serialization.
>
> Hope this helps.
>
> Daryoush
>
> On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
> hello,
>
> what would you think of an additional annotation for the
> webservice class like @TypeMapping that provides properties
> like the wsdd-typemapping?
>
> i know that this has nothing to do with jsr181 but with axis,
> but this would be a way to achive more flexibility (concerning
> things that normally would be done via wsdd)...
>
> would this be possible from a technical point of view, and
> would
> you integrate things like this into beehive?
> or what would be the way for customization?
>
> cheers,
> martin
>
>
> On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> > hello,
> >
> > i'm using beehive for writing some webservices, and like it
> very
> > much!
> >
> > now i want to have a custom type mapping for one class that
> is used
> > by more that one webservice in common, but i do not know how
> to do
> > this.
> >
> > what i have is the following:
> >
> > com.comp.ws.WSConsumerInfo
> > (this is a class that provides information about the
> webservice
> > consumer, this is expected by all webservices)
> >
> > com.comp.ws.srvc1.WebService1
> > com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
> >
> > com.comp.ws.srvc2.WebService2
> > com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
> >
> > both webservices define their own targetNamespace, e.g.
> > "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
> >
> > when the wsdl for a service is generated, the serializer
> creates
> > only the namespace for the service, and the WSConsumerInfo
> is
> > created in the same namespace. so, each webservice gets it's
> own
> > WSConsumerInfo, what is not desired, because the client's
> shall
> > get the WSConsumerInfo as a shared concept, too.
> > i'd like to have the WSConsumerInfo generated in a common
> namespace
> > "http://ws.comp.com".
> >
> > is there any way to achieve this with beehive?
> >
> > thanx for your help,
> > cheers,
> > martin
> >
> >
> --
> Martin Grotzke
> Hohenesch 38, 22765 Hamburg
> Tel. +49 (0) 40.39905668
> Mobil +49 (0) 170.9365656
> E-Mail martin.grotzke@javakaffee.de
> Online http://www.javakaffee.de
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBC9jSS7FvOl7Te+pYRAuBCAJwPkUSm+dw1h7k
> ++srrivAfxwIEPACgncgv
> oVPdxZeypr4wH5Ndf2Yg4FA=
> =xYUK
> -----END PGP SIGNATURE-----
>
>
>
>
>
--
Martin Grotzke
Hohenesch 38, 22765 Hamburg
Tel. +49 (0) 40.39905668
Mobil +49 (0) 170.9365656
E-Mail martin.grotzke@javakaffee.de
Online http://www.javakaffee.de
Re: wsdl/schema generation and custom type mapping
Posted by Daryoush Mehrtash <dm...@gmail.com>.
Martin,
Beehive supports three different types in a Web Service.
1. POJO
2. XMLBean types
3. Axis types
If you use a POJO as your type, beehive would introspect the class and
create its type mappings. It makes your life easier since the introspection
walks up the class hierarchy and is smart enough to recognise other Axis or
XMLBean types along the way. In this case if you use a same type in two
different web services (with different default namespace) you would get
different schema. Which is not what you want.
The other two alternative (Axis types, and XMLBeans) on the other hand
expect the types to do their own serializations. In both of these cases you
would be able to get your desired effect, i.e. to reuse the type and still
get the same schema.
XMLBean types are always generated from schema. They would be an ideal case
if you want to start the web service development by defining the schema of
the types. You would write your schema and use XMLBean tools to generate the
types and then use the types in your web services. You can also take this
one step further by using an XML editor to first write the complete WSDL
(types, messages, port, binding..) then use beehive to generate your types
and the annotated web service class. (see samples/wsm-addressbook-fromWSDL).
Your other Alternative is to use Axis types. You would need this if you are
using RPC style, or if you want to have fine grain control over the
serialization process. You can either write them by hand or use Axis tools
to generate the types. This is documented here:
http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
Note that you would only need the data types that are generated. To write
them by hand you would need to implement the three public static methods
(getTypeDesc, getSerailizer, and getDeserailizer) for each type. I attached
an example for StateType class that was generated by Axis tools, it should
give you an idea what you would need to implement. You can drop this class
in any JWS, and you should see the type being serialized to
http://byXmlBeanNS (just a name i used when i created the type) namespace.
Axis also has tools to generate the Helper classes that do serialization
(see Axis documentation for more on this).
To summarize.... If you are doing RPC style, then use the Axis types (either
generated or by hand). If you are using Document style then use XMLBeans if
you know the schema of the types, or use Axis types if you want to start
from Java and write your own serialization.
Hope this helps.
Daryoush
On 8/7/05, Martin Grotzke <ma...@javakaffee.de> wrote:
>
> hello,
>
> what would you think of an additional annotation for the
> webservice class like @TypeMapping that provides properties
> like the wsdd-typemapping?
>
> i know that this has nothing to do with jsr181 but with axis,
> but this would be a way to achive more flexibility (concerning
> things that normally would be done via wsdd)...
>
> would this be possible from a technical point of view, and would
> you integrate things like this into beehive?
> or what would be the way for customization?
>
> cheers,
> martin
>
>
> On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> > hello,
> >
> > i'm using beehive for writing some webservices, and like it very
> > much!
> >
> > now i want to have a custom type mapping for one class that is used
> > by more that one webservice in common, but i do not know how to do
> > this.
> >
> > what i have is the following:
> >
> > com.comp.ws.WSConsumerInfo
> > (this is a class that provides information about the webservice
> > consumer, this is expected by all webservices)
> >
> > com.comp.ws.srvc1.WebService1
> > com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
> >
> > com.comp.ws.srvc2.WebService2
> > com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
> >
> > both webservices define their own targetNamespace, e.g.
> > "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
> >
> > when the wsdl for a service is generated, the serializer creates
> > only the namespace for the service, and the WSConsumerInfo is
> > created in the same namespace. so, each webservice gets it's own
> > WSConsumerInfo, what is not desired, because the client's shall
> > get the WSConsumerInfo as a shared concept, too.
> > i'd like to have the WSConsumerInfo generated in a common namespace
> > "http://ws.comp.com".
> >
> > is there any way to achieve this with beehive?
> >
> > thanx for your help,
> > cheers,
> > martin
> >
> >
> --
> Martin Grotzke
> Hohenesch 38, 22765 Hamburg
> Tel. +49 (0) 40.39905668
> Mobil +49 (0) 170.9365656
> E-Mail martin.grotzke@javakaffee.de
> Online http://www.javakaffee.de
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBC9jSS7FvOl7Te+pYRAuBCAJwPkUSm+dw1h7k++srrivAfxwIEPACgncgv
> oVPdxZeypr4wH5Ndf2Yg4FA=
> =xYUK
> -----END PGP SIGNATURE-----
>
>
>
Re: wsdl/schema generation and custom type mapping
Posted by Martin Grotzke <ma...@javakaffee.de>.
hello,
what would you think of an additional annotation for the
webservice class like @TypeMapping that provides properties
like the wsdd-typemapping?
i know that this has nothing to do with jsr181 but with axis,
but this would be a way to achive more flexibility (concerning
things that normally would be done via wsdd)...
would this be possible from a technical point of view, and would
you integrate things like this into beehive?
or what would be the way for customization?
cheers,
martin
On Sun, 2005-08-07 at 14:17 +0200, Martin Grotzke wrote:
> hello,
>
> i'm using beehive for writing some webservices, and like it very
> much!
>
> now i want to have a custom type mapping for one class that is used
> by more that one webservice in common, but i do not know how to do
> this.
>
> what i have is the following:
>
> com.comp.ws.WSConsumerInfo
> (this is a class that provides information about the webservice
> consumer, this is expected by all webservices)
>
> com.comp.ws.srvc1.WebService1
> com.comp.ws.srvc1.MyWS1Request (associates WSConsumerInfo)
>
> com.comp.ws.srvc2.WebService2
> com.comp.ws.srvc2.MyWS2Request (associates WSConsumerInfo)
>
> both webservices define their own targetNamespace, e.g.
> "http://srvc1.ws.comp.com" and "http://srvc2.ws.comp.com".
>
> when the wsdl for a service is generated, the serializer creates
> only the namespace for the service, and the WSConsumerInfo is
> created in the same namespace. so, each webservice gets it's own
> WSConsumerInfo, what is not desired, because the client's shall
> get the WSConsumerInfo as a shared concept, too.
> i'd like to have the WSConsumerInfo generated in a common namespace
> "http://ws.comp.com".
>
> is there any way to achieve this with beehive?
>
> thanx for your help,
> cheers,
> martin
>
>
--
Martin Grotzke
Hohenesch 38, 22765 Hamburg
Tel. +49 (0) 40.39905668
Mobil +49 (0) 170.9365656
E-Mail martin.grotzke@javakaffee.de
Online http://www.javakaffee.de