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