Very Computer

My employer wishes to design a large scale, 3-tier, client/server
application.  The middle tier would be composed of CORBA objects,
factories, managers, in short business logic model.  The 3rd tier will
be a database, and the client, well -- just the client.

My question is regarding the "business logic" (middle) tier which will
be written using CORBA.  I have done some analysis and determined that
for any non-trivial middle tier one would need at least the following:

1. Naming service, to identify root objects and start of navigation
hierarchies
2. Relationship service to store relations between objects
3. Transaction service to promote data integrity between object

Other than the Naming and Event services, I am not sure if the
Relationship service or Transaction service exist for any of the ORBs
yet.  

Have any one put together a non trivial business logic model using
CORBA?  How did you solve the issues of relations, transactions,
persistency, between your objects?

Once such a dynamic model is put together how do I make sure that the
client stays synchronized with the data at the server(s).  I guess I
could use the Observer pattern, but a number of people have advised
against using call back mechanisms in a large scale application.  Are
there other techniques that can be used to keep the client always
up-to-date with the latest "picture" on the server?

Are there any conferences, or sources where I can find out some
techniques that people use to put together middle tiers?  Are there
any case studies published describing what people have done, and how
it worked out for them?

Thanks for your help.

-AP_

Quote:>My employer wishes to design a large scale, 3-tier, client/server
>application.  The middle tier would be composed of CORBA objects,
>factories, managers, in short business logic model.  The 3rd tier will
>be a database, and the client, well -- just the client.

>My question is regarding the "business logic" (middle) tier which will
>be written using CORBA.  I have done some analysis and determined that
>for any non-trivial middle tier one would need at least the following:

>1. Naming service, to identify root objects and start of navigation
>hierarchies
>2. Relationship service to store relations between objects
>3. Transaction service to promote data integrity between object

>Other than the Naming and Event services, I am not sure if the
>Relationship service or Transaction service exist for any of the ORBs
>yet.  

>Have any one put together a non trivial business logic model using
>CORBA?  How did you solve the issues of relations, transactions,
>persistency, between your objects?

>Once such a dynamic model is put together how do I make sure that the
>client stays synchronized with the data at the server(s).  I guess I
>could use the Observer pattern, but a number of people have advised
>against using call back mechanisms in a large scale application.  Are
>there other techniques that can be used to keep the client always
>up-to-date with the latest "picture" on the server?

>Are there any conferences, or sources where I can find out some
>techniques that people use to put together middle tiers?  Are there
>any case studies published describing what people have done, and how
>it worked out for them?

>Thanks for your help.

>-AP_

You may want to consider buying instead of building.

Look at PowerTier from Persistence or Secant Extreme from Secant for
persistence servers that provide object-relational mapping.  PowerTier
provides an event service for synchronizing clients (I think).  Secant
whitepapers are good reading.  Look at application server products
like Gemstone or NetDynamics.   Iona provides OTS as a transaction
service.

Good luck.  Let me know how it goes.

Thanks.
-AP_

--Mike

Quote:

> Thanks.
> -AP_

You deploy a system using PowerTier, it works fine against your database
and with your clients. You're using Corba OTS.

Now, along comes a requirement to update the existing database using your
PowerTier server and a some records in a new Sybase database (for example)
with transaction safety. You can't do it. Why, I'm using OTS whats the
problem? You can't because, PowerTier does not support participation in an
XA transaction (although it does support two phase commit which you access
two databases from a PowerTier application but this is not the same thing).
This also means OTS is useless with it as the PowerTier server ignores the
transaction stuff anyway.

Another problem is scalability to large (ie number of tables, not size)
databases. For example, I've got a large database with like 200 tables. I
use PowerTier for this and again to get transaction safety, I need to put
all this in a single process. All the business logic also has to go inside
this process. I possibly have 100 people working on this. Can you imagine
trying to get that server stable when it has code from 100 developers
inside it. One mistake with the heap stuff and the whole process is history
and its a big job to debug it and find the fault. So, for large servers, I
don't think the development process can scale to large servers using
PowerTier.

Heres another example. My client is connected to a PowerTier transaction
and is currently in the middle of a long running transaction. Now, the
PowerTier process fails (for what ever reason). The client is hosed as all
the changes were stored in memory on the PowerTier server and the back end
database will be rolled back. Even, if the ORB reconnects the client to
another instance of the PowerTier server it's no good as all the data
changes were local to the other failed process. So, PowerTier servers do
not support the repair concept on failure. That is, if the server instance
the client is using fails, it is not possible or at least very difficult to
transparently fail over to a second instance with out some work loss if a
long running transaction was open.

But, having said all that, if the above is not important to you, it is a
very useful tool to have in the arsenal but you need to be aware of the
above especially the first point to avoid being burned later.