You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Soti, Dheeraj" <ds...@harris.com> on 2005/04/09 00:20:04 UTC

RE: Which is a better approach to avoid polymorphism and inherita nce

The internal representation the ContentRealization contains the full Content
model so it knows the type. When I modeled the same thing in WSDL I ran into
cyclic loop problem at the time of serialization as Content contained
ContentRealization and that again contained Content and so on. To overcome that
issue I replaced the full Content model with an Id in the API version of the
model. But now I face a different problem. May be I chose a wrong way to solve
that issue.

To answer your question the ContentRealization in WSDL doesn't contain the
content type but I can add it. This would be similar to the second approach I
suggested in my earlier mail. Combine all the fields from all the types and
create one model with an additional field that tells "Type"
(Program/Commercial).

Thanks

Dheeraj

-----Original Message-----
From: Anne Thomas Manes [mailto:atmanes@gmail.com] 
Sent: Friday, April 08, 2005 3:06 PM
To: axis-user@ws.apache.org
Subject: Re: Which is a better approach to avoid polymorphism and inherita nce


Sorry -- I mistyped...

Does the ContentRealization indicate the content type?

Anne

On Apr 8, 2005 5:56 PM, Soti, Dheeraj <ds...@harris.com> wrote:
> 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:atmanes@gmail.com]
> 
> 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 <ds...@harris.com>
> 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:atmanes@gmail.com]
> > 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 <ds...@harris.com> 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.
>