3D PLM Enterprise Architecture

What Is a CATlet

Basically a CATlet can be assimilated to a Java Bean but it is a more than a Java Bean in the way it is designed to fit inside the Portal and as such has built-in functionalities to enhance this integration. But don't mess with this: we didn't say a CATlet can only exist inside the Portal. As a standard Java Bean a CATlet can be instantiated anywhere outside the Portal and any Java Bean can be instantiated inside the Portal (but with a degraded integration).

A CATlet is a graphical container and is built around the model-view-controller paradigm (named MVC afterward). The CATlet is itself the controller of the whole component and aggregates its views and models. A CATlet can have many views and models but most of the time it has only one for each. Be careful that we use the term CATlet to represent two things: the whole component (Model View and Controller) as well as the controller itself. This may be confusing but in fact they represent quite the same thing: The CATlet is the graphical controller component added inside the Portal and it is the only part of the MVC, visible from outside.
All the intelligence of the MVC component is located in the CATlet (the Controller). The model is meant to store the data of this component and the view to display whole or part of these data. Model and view are instantiated by the CATlet. They should not know (i.e. no reference) each other or the CATlet that created them. This way you strongly reduce the tight between components and views or models can be reused in other contexts.
Now, these three components (model, view and controller) have to communicate which each others. As the CATlet knows (i.e. has a reference) the model and the view, the CATlet communicates with the model and the view via method calls. As the model knows neither the view nor the CATlet it can only communicate with them by sending events, subscription being through the CATlet. For the view it is the same kind of communication as for the model with the difference that usually the view doesn't have to directly communicate with the model.
The communication flow between these components is as follow:

• a user interaction occurs in the view, it is analyzed by the view and and the view warns the CATlet with an event that something happened
• the CATlet analyzes the view's event and edits the model with direct function calls.
• as the model is edited, it fires events to warn that its data have changed
• these event are received by the view that update its representation accordingly

[Top]

CATlet Concepts and Basic Processes

Main statements from this schema are that

• CATlets are independant component based on the model of java-beans and the model-view-controller structure
• As independant java-beans, CATlet can communicate with each other and with their container through different services like the CommonSupport or the Hookup for events publication.

To program a CATlet, a programmer needs to write the client model-view-controller of its CATlet (using base classes delivered by the infrastructure), write the communication classes (event listener and publisher).

[Top]

Making Components Reusable: the Java-Beans Component Model

A java-bean is a elementary Java component allowing to users to build other components. Each CATlet is also a java-bean and is itself made of other java-beans.

To be considered as a java-bean, a component must follow the Java Bean design patterns. These design patterns describe mainly how to define your object methods, its events and properties. Following this design pattern make a lot easier communication and connection between beans as well a configuration of your object at runtime. Please refer to the JavaBean specification document for more detail about this design pattern.

An important property of the java-beans event model is that to communicate, beans don't have to know each other at build time. This way, beans can be completely independent, providing the following benefits :

• communication between beans is standardized and easy to do : it helps understand existing code, as well as designing and implementing new code
• as beans contain no reference to other beans, they are independent and reusable in any environment welcoming beans
• thanks to the java-beans introspection mechanism, a bean can easily describes its interface at runtime, allowing it to be used in visual builders.

[Top]

Inside a CATlet: The beanified Model-View-Controller

Description and benefits

A CATlet is basically made of three kind of elements:

• the model, which basically contains data, editors on these data.
• the view which basically displays the data contained inside the model and processes user interactions.
• the controller which basically interprets the user interaction processed by the view and edits the model.

The beanified MVC protocol describes precisely the events and properties flows between the model, view and controller. The benefits of this protocol are:

• this protocol can be repeated over and over in a CATlet design : this help for the design.
• the infrastructure provides base classes to implement this protocol : this help for the implementation
• this protocol allows to attach more than one view to the same model
• this protocol allows to attach more than one model to the same view
• this protocol allows to create new views and attach them to an already
existing model without modifying it (if the model can provide its data in the right flavor)

Basic process

The controller must extend one of these classes CATlet or JCATlet (AWT or Swing implentation of the ICAtlet interface) from the package com.dassault_systemes.catweb.base.catlet. Within it you need to:

• manage the communication with other CATlets (see Communicating with other CATlets)
• implement the CATlet abstract methods to allow the Portal to communicate with your CATlet and manage its life cycle (see Communicating with the Portal and the CATlet life Cycle)
• create the views and models components. The controller is the only entity to have and keep a reference on its models and views
• as the CATlet is also a graphical container, handle the layout of its views (which have been previously added inside the CATlet)
• make the views subscribe to events fired by the models, at least PropertyChangeEvent but also ItemEvent or other model custom events
• subscribe the controller to events fired by the views
• edit and query the models

The model must extend the class Model (from package com.dassault_systemes.catweb.base.catlet.model). Within it you need to:

• store and retrieve data and warn by firing a PropertyChangeEvent each time the data have been changed
• provide edit and query methods on these data
• handle the selection of these data and warn by firing an ItemEvent each time the selection content has changed

The view must implement the interface ViewInterface (from package com.dassault_systemes.catweb.base.catlet.view). Within it you need to

• create the user interface objects
• upon reception of a PropertyChangeEvent which source is a model, retrieve data from this model and display them
• subscribe to low level interaction events from the user interface objects
• transform this low level events in high level events to re-dispatch them to the controller.

Communication flow at runtime

The following diagram shows the different kind of communication that exist between the models, views and controller :

[Top]

Communication between CATlets: the Hookup Mechanism

Description and benefits

The Hookup is a component delivered in the CATlet infrastructure that allows you to make your CATlet communicating with each other without knowing themselves.

The Hookup uses a publish-subscribe mechanism based on the java-beans events model. When a CATlet is interested in listening some events, it must get a reference on an object which fires these events to subscribe on it. When you don't have a reference on such object, just tell the Hookup that you are interesting in listening some particular events (this is called subscribing). On the other side, when you may fire events, tell the Hookup that you can fire these king of events (this is called publishing). This way, when the Hookup has a subscriber interested in listening events that one of its publishers fire, it will act as a third party and make this subscriber subscribes to this publisher (as defined in the java-beans event model). Up to this point, both beans are connected and when the publisher fires an event, the subscriber is notified on the corresponding listener interface (as defined in the java-beans event model).

At no moment the publisher had a reference on the subscriber nor the subscriber had a reference on the publisher. The drawback of this mechanism is that you can't control to which CATlet you fire your events, except if the events you fire contains additional information that will let the subscriber filter the received events.

An other mechanism provided by the Hookup is the notion of persistent events. If a publisher has fired an event and decided that this event will be persistent, each time a new subscriber declares itself as being interested in this kind of events, it will automatically receive this event.

Basic process

This describes briefly how to publish and subscribe

• a publishing CATlet must have a BeanInfo class describing all the events it may fire
• for each XXX event the CATlet may fire, it must implement a addXXXListener and removeXXXListener methods for the matching XXXListener interface
• the subscribing CATlet must implement the XXXListener interface that contains the methods on which this listener will be called back when the event is fired.
• when needed, the publishing CATlet must inform the Hookup that it may fire the events described in its BeanInfo class. At any time this publisher may also inform the Hookup that it no more wants to publish its events.
• when needed, the subscribing CATlet must inform the Hookup that it is interested in some kind of event. At any time this subscriber may also inform the Hookup that it is no more interested in receiving this event.
• when needed, a publisher may inform the Hookup that it wants to made this event persistent.

[Top]

Communication with the Portal Desktop

In order to benefit from services of the environment it lives in, the CATlet may communicate with it. Even if the CATlet's main and dedicated environment is the Portal desktop, it may have others environment it doesn't know.  This is why all the requests are processed to the CommonSupport which redirects them to interfaces which implementation differ from the environment. The requests this CommonSupport object support are:

• send various messages to display (errors, warnings, infos)
• show and hide waiting cursors for all CATlets
• query if the current mode is application or applet
• make the environment create and start a CATlet by its name
• display the properties of a CATlet
• display an URL

As the environment in which the CATlets live may change, some of these requests may be processed or not depending on the capabilities of the environment.

[Top]

The CATlet Life Cycle

The CATlet life cycle is the following one:

At each state of this life cycle, the CATlet may take special action:

• creation : the CATlet initialize itself. At this time, the CATlet is not already added in its environment (the Portal desktop for example)
• start : the CATlet is now added in its environment. This is in this state that the models and views are usually created. Events subscription and publishing may also take place here.
• activation : the CATlet has been activated by the end user and is now ready to receive user interaction.
• deactivation : the CATlet has been deactivated by the end user and does not receive user interaction any more.
• stop : the CATlet is about to removed from its environment. Events un-subscription and un-publishing usually take place here. Persistent data may also be saved here.
• cleanup : the CATlet is about to be destroyed. The CATlet must clean up itself to ease the task of the garbage collector.

[Top]

References

History

Copyright © 2000, Dassault Systèmes. All rights reserved.