The subscription api uses the operationalInfo structure. I know this
because it's one of the functions I added to the current version of juddi
for my company. The operationalInfo structure does contain a record of
every "uddi entity" in the form of the "entityKey" but it is really a
OneToOne foreign key relationship...not a parent.
If there's no pressing need that can be seen for the current UddiEntity, I'm
going to remove it as a separate entity. I am actually thinking I'm going
to use it as a super class for all the aforementioned "uddi entities". That
way, I can continue to call persist with a single method signature.
Additionally, there are fields that are common to all these entities
("lastUpdated" comes to mind). I'll use the table-per-subclass inheritance
pattern when annotating with JPA.
If anyone has any other suggestions, please let me know. I'll probably
start working on this later today or tomorrow.
Regards,
Jeff
-----Original Message-----
From: Tom Cunningham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 11:25 AM
To: [email protected]
Subject: Re: Question regarding persistence layer: UddiEntity
I'm fine with removing UddiEntity, but we probably do need the
uber-parent idea for some of the features (subscriptions for example -
see section C.2.2). Are we able to handle this through the persistence
layer instead?
Jeff Faath wrote:
>
> The cascade option already exists in the relationship. However, it is
> a OneToMany (ie. UddiEntity has a bunch of collections). I wasn't sure
> why UddiEntity was structured like this which indicates I might not be
> using it correctly. I can't find UddiEntity anywhere in the spec either.
>
> *From:* Kurt T Stam [mailto:[EMAIL PROTECTED]
> *Sent:* Tuesday, September 16, 2008 8:55 AM
> *To:* [email protected]
> *Subject:* Re: Question regarding persistence layer: UddiEntity
>
> We may be saying the same thing, but I mean adding an annotation
> saying something like:
>
> @OneToOne(cascade=CascadeType.ALL)
>
> on the child or parent entity.
>
> --K
>
>
>
> Jeff Faath wrote:
>
> No, that's what I want to avoid having to do.manually cascading the
> saves to the child UDDI objects. If the UddiEntity reference didn't
> exist, I could literally call the "persist" on the top level
> BusinessEntity and every child entity - services, bindings, etc -
> would save automatically.
>
> *From:* Kurt T Stam [mailto:[EMAIL PROTECTED]
> *Sent:* Monday, September 15, 2008 9:36 PM
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* Re: Question regarding persistence layer: UddiEntity
>
> Jeff are you cascading the saves into this UDDIEntity object as well?
>
> Jeff Faath wrote:
>
> Kurt, Tom,
>
> Have a question regarding the UddiEntity entity in the persistence
> layer. It appears its function is to be the uber-parent of all "uddi
> entities" - the principles being BusinessEntity, BusinessService,
> BindingTemplate, and Tmodel.
>
> http://uddi.org/pubs/uddi-v3.0.2-20041019.htm#_Toc85908007
>
> So, each one of these principle entities in the domain model contains
> a reference to its own UddiEntity. In the DB schema, this simply
> translates to the entity key in the uddi_entity table, and as a
> result, each entity's primary key has a foreign key constraint tied to
> this table.
>
> My question is: I'm curious as to the usefulness of this structure.
>
> At first, I thought it fit well, because it allowed me to create a
> persist method with a single signature (ie. persistEntity(UddiEntity
> ue)). However, as I'm building out more of the logic - particularly as
> I'm starting to incorporate the built-in UDDI hierarchies - it is
> causing problems. It is interfering with the natural cascading saves
> that can exist in the UDDI hierarchy. Because each "entity" has this
> reference, I receive this persistence error, "object references an
> unsaved transient instance.", when trying to save an entity with child
> "uddi entities" (I'm using a very simple example of one BusinessEntity
> with one BusinessService - and the BusinessService has no child entities).
>
> There might be a use for this structure that I'm not seeing. But as it
> stands with the publishing API, it clashes with the ability to perform
> cascading saves. I can work with it if need be, but I'd have to write
> code that saves each "uddi entity" separately, even when the entity is
> provided as a child of a parent entity.
>
> -Jeff
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
