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: domain of dmehrtash@gmail.com designates
 64.233.170.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Ye7KV9p2yoUfCgyzN0ZDYmckhniyfmHr7/pv1kuxMw0A9Oowp3rjk3TLu4wKgm3SUegbihgUIKU6SmxmmSlIcUwbtjMRoFPnfTQDXkl0IsWmVxe2ad2DyaEIz3j4J15WfnJe92D5DUcha7JwD1VNAz+I1Tk4+FcmWN4wO3qUmgc=
Message-ID: <e5b8e9790508072258496863c9@mail.gmail.com>
Date: Sun, 7 Aug 2005 22:58:16 -0700
From: Daryoush Mehrtash <dmehrtash@gmail.com>
To: Beehive Users <beehive-user@incubator.apache.org>
Subject: Re: wsdl/schema generation and custom type mapping
In-Reply-To: <1123450680.4258.118.camel@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <1123417034.4258.22.camel@localhost>
	 <1123431570.4258.85.camel@localhost>
	 <e5b8e979050807110339d9fd7e@mail.gmail.com>
	 <1123450680.4258.118.camel@localhost>

Comments  below

On 8/7/05, Martin Grotzke <martin.grotzke@javakaffee.de> wrote:
> daryoush,
>=20
> thank you for your great and extensive answer!
>=20
> 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?
>=20

When you have a=20

      @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. =20

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.

>=20
> 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.
>=20

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).
>=20

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?
>=20
>=20

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. =20

> thanx for your help,
> martin
>=20
>=20

You welcome,

Daryoush
>=20
>=20
>=20
> 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#WSDL2JavaBuildingStubsSk=
eletonsAndDataTypesFromWSDL
> >
> > 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 <martin.grotzke@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=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
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>=20
> iD8DBQBC9n837FvOl7Te+pYRAhOcAKCdlYE1ewn/L9m4dc6CL71V4EAu1wCgtK2w
> Dgi0xn1we0VzV8/f7mAdj6c=3D
> =3DHzL9
> -----END PGP SIGNATURE-----
>=20
>=20
>=20


--=20
Daryoush

Weblog:  http://perlustration.blogspot.com/