Mailing-List: contact beehive-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Users" <beehive-user@incubator.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Subject: Re: wsdl/schema generation and custom type mapping
From: Martin Grotzke <martin.grotzke@javakaffee.de>
To: Beehive Users <beehive-user@incubator.apache.org>
In-Reply-To: <e5b8e979050808160051e1259a@mail.gmail.com>
References: <1123417034.4258.22.camel@localhost>
	 <1123431570.4258.85.camel@localhost>
	 <e5b8e979050807110339d9fd7e@mail.gmail.com>
	 <1123450680.4258.118.camel@localhost>
	 <e5b8e9790508072258496863c9@mail.gmail.com>
	 <1123494206.3944.57.camel@localhost>
	 <e5b8e97905080810565c12459b@mail.gmail.com>
	 <1123540425.3928.16.camel@localhost>
	 <e5b8e979050808160051e1259a@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="=-cCK2/UBmKn5Jc2+lHJN7"
Date: Fri, 12 Aug 2005 10:04:09 +0200
Message-Id: <1123833849.3887.28.camel@localhost>
Mime-Version: 1.0

--=-cCK2/UBmKn5Jc2+lHJN7
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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.
> >=20
>=20
>=20
>=20
> FYI, you should check out  this paper:
>=20
> http://www.hpl.hp.com/techreports/2005/HPL-2005-83.pdf
>=20
> It  has a some good points on the importance and power of the XML
> schema in defining the service.
>=20
> Daryoush
>=20
> On 8/8/05, Martin Grotzke <martin.grotzke@javakaffee.de> wrote:
> > On Mon, 2005-08-08 at 10:56 -0700, Daryoush Mehrtash wrote:
> > > On 8/8/05, Martin Grotzke <martin.grotzke@javakaffee.de> wrote:
> > > > On Sun, 2005-08-07 at 22:58 -0700, Daryoush Mehrtash wrote:
> > > > > On 8/7/05, Martin Grotzke <martin.grotzke@javakaffee.de> wrote:
> > > > i have s.th. like the following:
> > > >
> > > > package com.comp.ws.srvc1;
> > > > @WebService(targetNamespace=3D"srvc1.ws.comp.com")
> > > > class WebService1 {
> > > >   @WebMethod void doFoo( WS1Request req ){}
> > > > }
> > > >
> > > > package com.comp.ws.srvc2;
> > > > @WebService(targetNamespace=3D"srvc2.ws.comp.com")
> > > > class WebService2 {
> > > >   @WebMethod void doBar( WS2Request req ){}
> > > > }
> > > >
> > > > where both WS1Request and WS2Request have their domain properties a=
nd
> > > > associate an instance of the class
> > > >   com.comp.ws.WSConsumerInfo.
> > > > WSConsumerInfo is a technically motivated class that is written onc=
e
> > > > and used for all webservice invokations.
> > > >
> > > > the problem now was, that i implemented the getTypeDesc (with names=
pace
> > > > "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 WS1Reque=
st
> > > > and WS2Request, with the _complete_ type description for these clas=
ses,
> > > > with all their properties, that i don't want to customize.
> > > >
> > > > i don't understand why i have to write type descriptions for classe=
s
> > > > that i do not want to customize, why it's not enough to provide thi=
s
> > > > information in the WSConsumerInfo - but this is probably an axis-th=
ing.
> > > >
> > >
> > >
> > > 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.
> >=20
> > >  and you want to have WSConsumerInfo to
> > > have common namespace in both web services.  Right?
> > yes, that's right :)
> >=20
> > 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.
> >=20
> >=20
> > > 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.
> >=20
> >=20
> > > > again the question concerning jaxb 2.0 and annotations like @XmlTyp=
e:
> > > > 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) supporte=
d
> > > 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.
> >=20
> >=20
> > > Hope it helps
> >=20
> > 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.
> >=20
> > thanx again,
> > cheers,
> > martin
> >=20
> >=20
> >=20
> > >
> > > 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 t=
o use
> > > > > and implement its requirement.
> > > > >
> > > > > > currently, i'm a little bit confused if my aims are kind of str=
ange,
> > > > > > 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 servic=
es
> > > > > that are using the same underlying types.  There is nothing "stra=
nge"
> > > > > about it, it makes a lot of sense, you would want your types to b=
e 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 Ja=
va.
> > > > >
> > > > > > 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 sin=
ce the
> > > > > > > introspection walks up the class hierarchy and is smart enoug=
h to
> > > > > > > recognise other Axis or XMLBean types along the way.   In thi=
s case if
> > > > > > > you use a same type in two different web services (with diffe=
rent
> > > > > > > default namespace) you would get different schema.  Which is =
not what
> > > > > > > you want.
> > > > > > >
> > > > > > > The other two alternative (Axis types, and XMLBeans) on the o=
ther 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 b=
e an
> > > > > > > ideal case if you want to start the web service development b=
y
> > > > > > > defining the schema of the types.  You would write your schem=
a 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 a=
n XML
> > > > > > > editor to  first write the complete WSDL (types, messages, po=
rt,
> > > > > > > binding..) then use beehive to generate your types and the an=
notated
> > > > > > > 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 co=
ntrol
> > > > > > > over the serialization process.  You can either write them by=
 hand or
> > > > > > > use Axis tools to generate the types.   This is documented he=
re:
> > > > > > >
> > > > > > > http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuild=
ingStubsSkeletonsAndDataTypesFromWSDL
> > > > > > >
> > > > > > > Note that you would only need the data types that are generat=
ed. To
> > > > > > > write them by hand you would need to implement the three publ=
ic static
> > > > > > > methods (getTypeDesc, getSerailizer, and getDeserailizer)  fo=
r each
> > > > > > > type.  I attached an example  for StateType class that  was g=
enerated
> > > > > > > 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 shoul=
d see the
> > > > > > > type being serialized to http://byXmlBeanNS (just a name i us=
ed when i
> > > > > > > created the type)  namespace.  Axis also has tools to generat=
e the
> > > > > > > Helper classes that do serialization (see Axis documentation =
for more
> > > > > > > on this).
> > > > > > >
> > > > > > > To summarize....  If you are doing RPC style, then use the Ax=
is types
> > > > > > > (either generated or by hand).  If you are using Document sty=
le 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 <martin.grotzke@javakaffee.de> wrot=
e:
> > > > > > >         hello,
> > > > > > >
> > > > > > >         what would you think of an additional annotation for =
the
> > > > > > >         webservice class like @TypeMapping that provides prop=
erties
> > > > > > >         like the wsdd-typemapping?
> > > > > > >
> > > > > > >         i know that this has nothing to do with jsr181 but wi=
th axis,
> > > > > > >         but this would be a way to achive more flexibility (c=
oncerning
> > > > > > >         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 wro=
te:
> > > > > > >         > 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 cl=
ass 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 WSCons=
umerInfo)
> > > > > > >         >
> > > > > > >         >   com.comp.ws.srvc2.WebService2
> > > > > > >         >   com.comp.ws.srvc2.MyWS2Request (associates WSCons=
umerInfo)
> > > > > > >         >
> > > > > > >         > both webservices define their own targetNamespace, =
e.g.
> > > > > > >         > "http://srvc1.ws.comp.com" and "http://srvc2.ws.com=
p.com".
> > > > > > >         >
> > > > > > >         > when the wsdl for a service is generated, the seria=
lizer
> > > > > > >         creates
> > > > > > >         > only the namespace for the service, and the WSConsu=
merInfo
> > > > > > >         is
> > > > > > >         > created in the same namespace. so, each webservice =
gets it's
> > > > > > >         own
> > > > > > >         > WSConsumerInfo, what is not desired, because the cl=
ient'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=3D
> > > > > > >         =3DxYUK
> > > > > > >         -----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/L9m4dc6CL71V4EAu1wCgtK2=
w
> > > > > > Dgi0xn1we0VzV8/f7mAdj6c=3D
> > > > > > =3DHzL9
> > > > > > -----END PGP SIGNATURE-----
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v1.4.1 (GNU/Linux)
> > > >
> > > > iD4DBQBC9yk97FvOl7Te+pYRAvMqAJi+IBLTqsOhvwj9EgO8M1LhLgw9AJ9VS6WT
> > > > I/5LW6cKclb+TtAlPBesFw=3D=3D
> > > > =3DZC3r
> > > > -----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
> >=20
> >=20
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> >=20
> > iD8DBQBC993I7FvOl7Te+pYRAm9BAJ96OM0P6gm56U+xWm0TyAAXhFnTOwCgkl7Y
> > +A/7L7F+vnadTSxARk241GU=3D
> > =3Dl38C
> > -----END PGP SIGNATURE-----
> >=20
> >=20
> >=20
>=20
>=20
>=20
--=20
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

--=-cCK2/UBmKn5Jc2+lHJN7
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBC/Ff57FvOl7Te+pYRAmJdAKCmB7DCEGs5hudVCRvI2VkWDQKxcgCfbnnj
hxCudj9tP/4E4jxWUllCmks=
=Cy2a
-----END PGP SIGNATURE-----

--=-cCK2/UBmKn5Jc2+lHJN7--