This section describes the internal structures of the different Business Aspect Servers within PROTO610. Essentially, this is the same as described in the Servers section (Some Interesting Sample Aspect Servers)

Original document by Fredrik D. Alink (1-10-2004)
Document revised on 1-9-2005

Within PROTO610, the following Business Aspects are defined:

Essentially on Business Aspects is that they only control the aspect involved, and not the “embedded” Business Objects. This is explicitly shown in the relationship models.

Basicly, Data are “flat” objects. The only thing you need to know is the property and it's value of the originating object that's meant in the Data and the originating object's identification. Example: Person Id's name = “Jannes”.

If you want to structure Data, this can be done by referencing to them from a Context, to be Controled in a (preferably) separate “Data Model Control” Business Aspect Server.

GME Control contains a description of the structure of the IMA PROTO610 Business Aspect Servers. Every object in any of those Servers is described in an Element. Depending on the structure of each Business Aspect Server, an Element is referencing to another one or not.

In general, any Business Aspect Element refers to (so far) one (or more) Business Construct Elements, each of which refers to primary Business Object Elements. Depending on the Aspect Servers structure, Business Object types refer to other Business Object types.

Through the “produceWorkorder” Business Service, Process Control provides the Engines in the IMA Model with Work Orders and their Task Process definitions.

To be able to do so, the Process Control Business Aspect Server maintains all the type definitions for any specific Work Order and Task Process items.

After a Work Order is made available to an Engine to be performed, it's nomore controled by the Process Control Business Aspect Server. From then on, it's the actions and events for the Engine that change the Work Order in a way as if it was a Work Order File. Also, the Work Order can be kept in it's current status by any applicable Scheduling Control Queue. Examples: the next Work Order in an Actors Work Order Queue, or a finished Work Order in the Archive File.

Resource Control is there to maintain any Resources necessary within a specific IMA model. In PROTO610, only the use of Resources as Actor, responsible for the performance of a Task on an Engine, is relevant. But any additional Resources needed (and used) for a Task can be maintained within this Business Aspect.

A Resource is a “role reference” to any physical or non-physical object that can play this “role”. In PROTO610, the following objects are provided (though not all used) as Resource: a Person, a Computer, an Engine, a Truck, a Clock. Only Persons and a Clock are really used in PROTO610.

So far, for any Resource, the Tasks are defined in which this Resource can play the role of the responsible Task performing Actor. For each Task, specific Resource preferences and authorizations can be defined. For other uses, the Aspect has to be extended.

The Scheduling Control Business Aspect Server is the most complicated of the PROTO610. It's a dynamic context providing aspect for any objects to be “scheduled”. That is, to be placed in a queue for later use or release.

The Server provides any number of individual Schedulers. In PROTO610, 3 Schedulers are used: the Work Order Scheduler, the Mail Scheduler and the Archive. All of them have Work Orders as (Queue) Elements in their Queue tokens.

Queues are organised in Queue Pools. Each of those is of a specific Queue Type. Queue Pools can be generic (the General Pool), or Resource or Task specific. In this last cases, relevant Queue Pools are defined, pointing to the applicable Resource or Task. The Work Order Scheduler, the Mail Scheduler and the Archive use Resource Pools, as they are all defined as Resource related.

The following Queue Types are available:

The above describes how tokens are placed into any relevant Queue. Services are available to get tokens out of their Queue. But in this case, all Queues together are seen as one Overall Queue. Tokens are made available, based on given selection criteria. Criteria can be: the Scheduler, the Resource involved, the Task involved, the first token from the resulting Queue, the last token from the resulting Queue, et cetera.

To decide between Queues when making their tokens available, every Queue Type is provided with a Weighting Mechanism. Choosing between different Types (Event vs. Order) is done based on the defined weighting between the two.

User Control defines the authorizations of User Types within the IMA Model. This is, it defines what Tasks may be done by what Types of Resources in their roles as Actor (responsible for the performance of a Task). It also defines which Interfaces are available for this User Type's Tasks, so that a specific Resource can choose it's preference amongst this set of Interfaces.

User Control is a context oriented Aspect. It provides any resources (Person, Computer, Engine, Truck, Clock) with a User Type context.