OpenEdge Reference Architecture Quick Reference Guide

Hi Theo

Firstly don't forget that the components at this level are abstract, and therefore not tied to a specific implementation (classes or persistent procedures). However, whether you choose to implement using classes or p.procedures, it would seem to make sense that you have a single object instance for a given object type to manage the Data Instance, that is then passed through the layers. For example, you would have a single Customer Business Entity instance, that manages a Customer Data Instance (such as a Prodataset which contains one or more customer records). This is different I know, to the OO concept of having each customer record itself being an instance, which to me seems to go against some of the key differentiators of the ABL, in that it is a data aware language. So we are differentiating between the object instance and it's data (Data Instance), else how can one manage objects and their state in a stateless environment, without lots of overhead! Were not saying these are global objects across all agents.

I think that this is a very key point ... if perhaps a bit of a

sore one for those of us who would like a multi-threaded session.

In a language like Java, one is likely to have a single JVM

operating on a each machine, but potentially quite a lot going on

within that one JVM. In ABL, each ABL session has its own AVM which

has only limited channels of communication with the other AVMs on

the same machine. If one had a single VM for all sessions and many

sessions consuming say Customer objects, one might well want to

have multiple suppliers of Customer objects in order to provide

load balancing and performance. But, with multiple independent VMs,

it it highly unlikely that one could derive a performance benefit

by deploying multiple sources within each VM.

Hi Theo

Firstly don't forget that the components at this

level are abstract, and therefore not tied to a

specific implementation (classes or persistent

procedures).

Well in that case it's at least a bit confusing using "singleton" against abstract concepts. But OK....

However, whether you choose to

implement using classes or p.procedures, it would

seem to make sense that you have a single object

instance for a given object type to manage the Data

Instance, that is then passed through the layers.

For example, you would have a single Customer

Business Entity instance, that manages a Customer

Data Instance (such as a Prodataset which contains

one or more customer records).

So in your vision you will never have a situation where you need two prodatasets for a certain data instance? So this Business Entity will always represent just one view and filter during a service request?

This is different I

know, to the OO concept of having each customer

record itself being an instance, which to me seems

to go against some of the key differentiators of the

ABL, in that it is a data aware language.

I know...

So we are

differentiating between the object instance and it's

data (Data Instance), else how can one manage

objects and their state in a stateless environment,

without lots of overhead!

Well "stateless" refers to the service call: all context must be available to process the call at service entry. That's something different than having no state at all in a class instance. Other environments create a session context, a transaction context, a security context, etc. on service entry for instance. This is legal once you're inside the AppServer's boundaries. Or are you planning on running the Business Entities on different AppServer partitions as well? That will be a rather complex environment, transaction wise I mean.

Were not saying these are

global objects across all agents.

Not but once things are "static", "global" it means you cannot have any state in the object itself else your object can't be reentrant.

I suppose that my own focus in my reaction to this document is not so much to focus on the emphasis on singletons, but rather to focus on the decomposition of the problem. I.e., rather than the Data Source and Data Access structure I see hear, I am more inclined to a Mapper and Finder structure. With a Finder/Mapper discipline, one could well decide to make the Mapper a singleton within the context of a single-threaded session since there would be little advantage to parallelism and potential advantages to having a single source. If there was to be an advantage in parallelism, I would be more inclined to make that at the level of parallel services, each of which could still have a singleton Mapper per entity.

But, like you, I am inclined not to make the Finder a singleton nor does it seem to me that the Domain or Business Entity object should be a singleton. Surely, even within the context of a single-threaded session there are cases where one needs multiple instances of Customer or Order.

But, like you, I am inclined not to make the Finder a

singleton nor does it seem to me that the Domain or

Business Entity object should be a singleton.

Surely, even within the context of a single-threaded

session there are cases where one needs multiple

instances of Customer or Order.

In working with my procedure manager, I've found situations where singletons, singleton-to-a-context, and non-singleton instances all have useful places in an application.

Not having singletons isn't "the" problem - not having a variety of singletons to use on a given problem space - is.

Were not saying these are global objects across

all agents.

I think that this is a very key point ... if perhaps

a bit of a sore one for those of us who would like a

multi-threaded session.

But we have to design for the platform we have

snip..

So in your vision you will never have a situation

where you need two prodatasets for a certain data

instance? So this Business Entity will always

represent just one view and filter during a service

request?

I don't think anyting I've said states that a Data Instance couldn't be made up of 1 or more prodatasets, that will depend on a given implemenation.

Well "stateless" refers to the service call: all

context must be available to process the call at

service entry. That's something different than having

no state at all in a class instance. Other

environments create a session context, a transaction

context, a security context, etc. on service entry

for instance. This is legal once you're inside the

AppServer's boundaries. Or are you planning on

running the Business Entities on different AppServer

partitions as well? That will be a rather complex

environment, transaction wise I mean.

Sure, and indeed one of the first processes within the Service Provider would be to reconstitue any required context and state, if I implied something different, or the doc implies that then this is misleading and should be clarified.

And lobby for

the platform we want ... and should have.