Anne,

The ContentRealization do have an Id. Each "Content" contains an array of
ContentRealization and each ContentRealization refers to its parent Content with
an Id (Please note this Id can be for a Content which is different from the one
that contains it). So my problem is that if the client is going to generate
client side classes using the WSDL then the findByXXX() methods have to know
what type of class to return ProgramContent or CommercialContent. I have to
specify the return type as output message of my operations in WSDL.

Even there are multiple implementations of ContentRealization so while defining
the "Content" I have to somehow specify the type of the array to tell which type
of ContentRealization it is.

                        0..n
Content ---------------->ContentRealization

                           ContentRealization
                                  ^
                                  |
                                  |
              -------------------------------------------
              ^                                          ^
              |                                          |
              |                             0..n         |
          ContentRealizationType1---------------ContentRealizationType2

Basically I have to flatten out the whole object model into an XML schema. That
includes handling inheritance, polymorphism, cyclic loops.

Thanks

Dheeraj


-----Original Message-----
From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]

Sent: Friday, April 08, 2005 4:05 PM
To: Hittesdorf,Michael
Subject: Re: Which is a better approach to avoid polymorphism and inheritance


Nice idea, but you should avoid <xsd:choice> groups.


Could you put an Id attribute into the ContentRealization type? That way the
client knows ahead of time what type to request.

Anne

On Apr 8, 2005 4:14 PM, Dheeraj,Soti <[EMAIL PROTECTED]>
wrote:
Anne,

Thanks for getting back to me.

I also like the first approach (because of clarity) but it is going to make the
life of the clients pretty difficult. E.g. I have another complex type
"ContentRealization" that keeps a reference to the parent "Content
(Program/Commercial)" with an Id. Now the client gets hold of this
"ContentRealization" and wants to fetch the details of the "Content" associated
with it. At this point it might not even know that whether this Id is for a
ProgramContent or a CommercialContent so which find method he'll use.
findProgramContentById() or findCommercialContentById()

I feel that I didn't explained the second approach well.

ProgramContent has fields F1, F2, F3
CommercialContent has fields F1, F2 and F4

So I'll create a new APIContent with fields F1, F2, F3, F4, Type. I'll define
the type as an enumeration of Program and Commercial in the WSDL. So the client
will populate the appropriate fields in the model based on the "type" and create
the content using a createContent(APIContent). Based on the "type" the service
layer can construct the appropriate internal model. The client can just issue
findXXX() commands and the service layer will return the APIContent with the
proper type set.

I thought of using xsd:anyType also but I read at some places that the
implementation of this is optional as per the specification and I have to make
sure that the service is interoperable.

Thanks

Dheeraj

> -----Original Message-----
> From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 08, 2005 2:49 PM
> To: axis-user@ws.apache.org
> Subject: Re: Which is a better approach to avoid polymorphism and 
> inheritance
>

> Definitely go with the first approach. JAX-RPC does not require 
> support for <xsd:union>, and very few products support it.
>

> Anne
>

> On Apr 6, 2005 4:36 PM, Soti, Dheeraj <[EMAIL PROTECTED]> wrote:
> >
> >
> > Hi,
> >
> > I have class structure like as shown below. I am using doc/literal
> wrapped
> > style and I don't want to expose concepts like polymorphism,
> inheritance and
> > overloading in my service methods. There are two ways to handle
this:
> > Define two different complex elements for each type of content. The 
> > advantage is its very clear and simple. The disadvantage is that
there
> are
> > many calls like findById, findByHouseId, findByName etc. So I'll end
> up
> > writing duplicate set of calls for each type of content Define a 
> > single complex element with union of the fields from both
and
> > introduce a field to store type. The advantage is that I only need
> single
> > set of calls. The disadvantage is the additional type. There is a
> saying
> > that "Adding type means killing your object".
> >
> >
> > I understand that this is not really axis related question but I
will
> highly
> > appreciate if some would like to share his experience with me.
> >
> > Thanks
> >
> > Dheeraj Soti
> >
> >
> >                           Content
> >                              |
> >            -----------------------------------------
> >            |                                       |
> >          CommercialContent              ProgramContent
>

> E-MAIL CONFIDENTIALITY NOTICE:  The contents of this e-mail message
and any attachments are intended solely for the
> addressee(s) and may contain confidential and/or legally privileged
information. If you are not the
> intended recipient of this message or if this message has been
addressed to you in error, please
> immediately alert the sender by reply e-mail and then delete this
message and any attachments. If you
> are not the intended recipient, you are notified that any use,
dissemination, distribution, copying, or
> storage of this message or any attachment is strictly prohibited.
>

E-MAIL CONFIDENTIALITY NOTICE:  The contents of this e-mail message and any
attachments are intended solely for the

addressee(s) and may contain confidential and/or legally privileged information.
If you are not the

intended recipient of this message or if this message has been addressed to you
in error, please

immediately alert the sender by reply e-mail and then delete this message and
any attachments. If you

are not the intended recipient, you are notified that any use, dissemination,
distribution, copying, or

storage of this message or any attachment is strictly prohibited.

Reply via email to