Jag PB component creating standard pb nvo's

(PB 7.01/Jag 3.01)
Does anyone see a problem using a standard stateless PB component which
creates and destroys standard PB nvo's?  It seems to work fine, and I'm
planning to convert the other nvo's to components eventually.  Also, some of
these standard pb objects do commits and rollbacks.   I set my component up
as stateless/requires transaction, and I use "UseContextObject=No", so I'm
hoping the commits/rollbacks get converted to SetComplete/SetAborts, but
since they are not actually components, is this happening?



0
Kevin
12/18/1999 8:49:12 PM
sybase.easerver 11371 articles. 0 followers. Follow

4 Replies
502 Views

Similar Articles

[PageSpeed] 35

On Sat, 18 Dec 1999 15:49:12 -0500, "Kevin" <kjr_23@yahoo.com.nospam>
wrote:
Since the NVOs are in Jaguar this should be happening

Jon Credit[TeamSybase]
CPD Professional PB6
DONT_SPAM_ME_JCredit@Sprynet.com
http://jcredit.home.sprynet.com

>(PB 7.01/Jag 3.01)
>Does anyone see a problem using a standard stateless PB component which
>creates and destroys standard PB nvo's?  It seems to work fine, and I'm
>planning to convert the other nvo's to components eventually.  Also, some of
>these standard pb objects do commits and rollbacks.   I set my component up
>as stateless/requires transaction, and I use "UseContextObject=No", so I'm
>hoping the commits/rollbacks get converted to SetComplete/SetAborts, but
>since they are not actually components, is this happening?
>
>

0
NOSPAM_JCredit
12/19/1999 9:34:12 PM
In article <jSobBjZS$GA.287@forums.sybase.com>, kjr_23@yahoo.com.nospam 
says...
> (PB 7.01/Jag 3.01)
> Does anyone see a problem using a standard stateless PB component which
> creates and destroys standard PB nvo's?  It seems to work fine, and I'm
> planning to convert the other nvo's to components eventually.  Also, some of
> these standard pb objects do commits and rollbacks.   I set my component up
> as stateless/requires transaction, and I use "UseContextObject=No", so I'm
> hoping the commits/rollbacks get converted to SetComplete/SetAborts, but
> since they are not actually components, is this happening?

Kevin - 

Why not convert the other nvos to "components" as well. I would think we 
want components only to talk to other components.

Just a thought.
Mark

-- 

Mark J. Pfeifer[TeamSybase]		Corporate Technology Partners, Inc.
mpfeifer @ sprynet.com		   Emerging Technology Solutions
					         www.ctpartners.com

                          e-Map Solutions Provider
0
see_msg
12/19/1999 10:51:55 PM
> > (PB 7.01/Jag 3.01)
> > Does anyone see a problem using a standard stateless PB component which
> > creates and destroys standard PB nvo's?  It seems to work fine, and I'm
> > planning to convert the other nvo's to components eventually.  Also,
some of
> > these standard pb objects do commits and rollbacks.   I set my component
up
> > as stateless/requires transaction, and I use "UseContextObject=No", so
I'm
> > hoping the commits/rollbacks get converted to SetComplete/SetAborts, but
> > since they are not actually components, is this happening?
>
> Kevin -
>
> Why not convert the other nvos to "components" as well. I would think we
> want components only to talk to other components.
>
> Just a thought.
> Mark

I agree, and as I said, I plan to convert them, but they're VERY complex and
will take quite a bit of time.  My interrim (sp?) solution was to keep this
"framework" in tact as pb nvo's and call them from the component.  Since Jag
runs the PB VM I figured this would be ok, but was concerned about
commits/rollbacks.  Any other comments/suggestions?


0
Kevin
12/20/1999 12:20:18 AM
To summarize in advance, not every NVO needs to be a component.

I was involved in a similar discussion a few months ago, with someone who
was convinced that every business entity had to be written as an OO-ish NVO
with stateful set/get methods and compiled as a component.  I had to quote
chapter and verse from Booch and the UML to convince him otherwise.

In my understanding of distributed applications, the components represent
interfaces not business entities.  You implement you business entities as
NVOs but then write other objects that use one or more of those business
objects to perform some task.  In some case the interfaces might map one to
one to the business objects.  However, implementing every NVO as a component
seems to complicate the process.

I've been confused by a lot of articles/presentations/etc suggesting that
components map to business entities and database tables and I'm not sure I
buy it.  Making everything a component gives you more partitioning if
something needs to change, but at what cost?

On the practical side, what is the cost to the server of more
inter-component calls?  And how does this compare to the impact of slightly
fatter component binaries because they have two or three NVOs being compiled
into them instead of just one?

So like I said at the beginning, not every NVO needs to be a component.  If
the other NVOs provide don't provide functionality that can be used outside
the object you've already converted to a component, why convert them.

These may simply be the rantings of a mad programmer,
Brian

Mark J. Pfeifer[TeamSybase] <see_msg@sprynet.com> wrote in message
news:MPG.12c70f75989f6ade9896ce@forums.sybase.com...
> In article <jSobBjZS$GA.287@forums.sybase.com>, kjr_23@yahoo.com.nospam
> says...
> > (PB 7.01/Jag 3.01)
> > Does anyone see a problem using a standard stateless PB component which
> > creates and destroys standard PB nvo's?  It seems to work fine, and I'm
> > planning to convert the other nvo's to components eventually.  Also,
some of
> > these standard pb objects do commits and rollbacks.   I set my component
up
> > as stateless/requires transaction, and I use "UseContextObject=No", so
I'm
> > hoping the commits/rollbacks get converted to SetComplete/SetAborts, but
> > since they are not actually components, is this happening?
>
> Kevin -
>
> Why not convert the other nvos to "components" as well. I would think we
> want components only to talk to other components.
>
> Just a thought.
> Mark
>
> --
>
> Mark J. Pfeifer[TeamSybase] Corporate Technology Partners, Inc.
> mpfeifer @ sprynet.com    Emerging Technology Solutions
>          www.ctpartners.com
>
>                           e-Map Solutions Provider


0
Brian
12/21/1999 7:40:02 AM
Reply: