Is there any business task sample code for OERA?

Hi Dale

There is a paper by John Sadd available here which talks about 'Designing Business Tasks' and we're also currently working on some new updated samples which will be available soon.

But to try and answer your questions in general terms.  The aim of the Business Task is to orchestrate & manage the calling of Business Entities in order to complete whatever task is being requested.  When you mention external business entities, are you referring to entities outside of your application?  The role of the service adapter is to add a level of isolation so that the knowledge of how to connect to external business entities or services is encapsulated in one place.  The theory being that the business task (or business entity) can make the call for data, but where that data ultimately comes from, or how it gets services should in many ways be transparent and it shouldn't care, so long as it gets access to data in the form it requires to execute it's business logic.   If the Business Entities being referenced by your Business Task are all within your application, then the implication is that you shouldn't need to go through a service adapter.

The other point for discussion is transaction scoping.  Others may disagree, and after all the OERA is a set of guidelines, so can be implemented in many ways, but in the definitions of the OERA we say that a Business Entity manages it's transaction scope, but if a Business Entity is called by a Business Task, then the Business Task manages the whole transaction scope for the task and the Business Entity then becomes a sub-transaction, so you can orchestrate the transaction across the the required entities.

HTH

Mike

I suggest that you think more about good OO principles in general (e.g., http://www.cintegrity.com/content/OOABL ) than getting too wrapped up in the speciifics of the terminology of those whitepapers.  The vocabulary used there was really more of a way to get people started thinking in the right direction than it was a real model for development and, frankly, the code in that series of whitepapers has been more often the focus of criticism than applause.  Neither that or the not-quite-OO examples in AutoEdge were ever intended to be models for production systems.

The key thing is to get yourself well oriented around OO principles.  Then the decomposition of the problem space into objects will happen fairly naturally.  You'll have to wait a bit, but you might find some ideas in my presentation for Exchange called Object Orientation:  Why, When, and How.

Hi

Thanks to both of you for the quick replies.

I look forward to the new samples and also the exhchange presentation.

We have just started trying to transform our old client server app and want to get of with the right start.

A service interface procedure gets called which initiates a bt object

     The bt object creates instances of be objects it needs to complete the task is this ok or should the be instances be created in the service interface procedure?

My way seems to work at the moment but I need to make sure that everything cleansup correctly and the passing of datasets and context are being used in the most efficient way.

It takes some getting used to but I'm sure it will become second nature soon.

Thanks again

Again, there is no right or wrong here, but typically I'd advise moving the responsibility of starting/stopping the components to a common place, such as a Service Manager.  That way, if you need to make chages you're only changing code in one place, as opposed to potentially having to make changes in every Service Interface.

Check out the following for some ideas:

http://communities.progress.com/pcom/docs/DOC-16528

http://communities.progress.com/pcom/docs/DOC-11118

http://communities.progress.com/pcom/docs/DOC-11638

Mike

It sounds like you are off to a reasonable start.  The task is the point of control so the task should be responsible for managing its components.

Mike is right that factories are a good pattern for actually building objects, but I think you are in the right direction by having the task in control of the lifecycle.

We have just started trying to transform our old client server app and want

to get of with the right start.

A service interface procedure gets called which initiates a bt object

The service interface should be as thin as possible (note that all my names below are OERA names):


/* params */
/* setup */

SecurityManager:EstablishSession(pcClientSessionId, ...)

oService = ServiceManager:GetService(pcService, ...).
oService:FetchData(...).

/* cleanup and return */


There will be work required to extract the ProDataSet from an object so that it can be moved across the wire (as there will be work required in the Service Adapter to receive that ProDataSet and to push it back into an object).

All of the hard work should happen in a commonly-accessible area, since a Service could be an entity or a task, and could have varying ways of being accessed, depending on (say) the UI or the user.

One of the beauties of using OO code is you can code to a common (say) IServiceProvider interface regardless of whether you're working with a service task or entity; this way the service interface doesn't know or care what it's dealing with, and the code there is much simpler, and easier to read, which in turn makes it less error-prone. So we hit the win-win-win trifecta :).

The bt object creates instances of be objects it needs to complete the

task is this ok or should the be instances be created in the service

interface procedure?

In keeping with the above, I'd suggest that the ServiceManager returns a fully-functional object: if it's a Task, it should have all of the relevant Entities created already; if it's an Entity, it should be "fully-formed" and ready to go. The service_interface.p should not deal with any of the lifecycle/creation work for the Task.

In general, I'd create a BusinessTask object that took an array of BusinessEntity objects as a constructor argument. That loose coupling allows you to change the way that the Entities are constructed without affecting the Task.

It takes some getting used to but I'm sure it will become second nature soon.

Indeed it does and will.

-- peter