FracTalk is a component-based programming platform compliant with the ObjectWeb Fractal specification. Fractal describes a hiearchichal component model with reflection facilities. These characteristics makes us choose Fractal as the model to use for experiments related to our research in software component. For sake of openness and flexibility, our implementation relies on a dynamic language (Smalltalk).
Programming with FracTalk
Makers and Directories
To ease development, FracTalk introduces two concepts: Makers and Directories.
Makers are object in charge of dealing of all low-level tasks that permits components definition. A makers framework is provided in order to take care of most of the job to do when defining a new kind of component. Developers has only to provide, the controller (membrane) description, the implementation description and the component type. The makers framework is supposed to be the backbone of a futur ADL.
Directories are persistent components which aim at storing other components (usually templates or factories) or components parts (e.g. types, signatures, ...). They allow having a kind of cache that encourage reuse. They are especially useful when it comes to defining interface signatures and types. An interface signature or type is defined only once and then reused in different component definitions.
Caption
Server Interface
Client Interface
Client Collection Interface
Optional Client Interface
Note: This representation apply to both primitive and composite components alike.
Smalltalk has an object that acts as a console which is accessible through the global variable Transcript. The goal of this example is to encapsulate the Transcript object into a simple FracTalk primitive component we name also 'Transcript'.
This component has only a single server interface which provides two operations:
show: aString
This operation takes one argument which is a string to display on the Transcript window
cr
This operation takes no argument and makes a carriage-return on the Transcript window
In this example we show how to build a composite component named 'SimpleChat', which is a very simple chat example. Two subcomponents are involved. One is the transcript borrowed from the previous example (see Transcript) and the second is a new component named 'Chatter' which uses the Transcript.
The Chatter component has:
One attribute: name of type String
One client interface requiring two operations:
show: aString
This operation takes one argument which is a string to be displayed.
cr
This operation takes no argument and makes a carriage-return
One server interface providing a single operation:
say: aString
This operation makes the component request displaying some text through the client interface. The text to be be displayed is prefixed by a carriage-return, the current time and the chatter name. The rest of the text is the aString argument.
Now we want to build a more complex (but still non-distributed). This example show an implementation for 2 chatters with GUI interfaces for the input and display of text. We use a composite component which represent an interactive chatter and a conference component which distribute a message sent by a chatter to all the chatters (including himself).
It shows the 3 types of binding (normal, export and import) and the use of collection interfaces.
General view:
Architecture details of the InteractiveChatter component. It uses TextDisplay component similar to the Transcript component shown above except that it encapsulate a new Transcript object instead of using it directly.
The Conference component has:
One collection of clients interfaces requiring two operations:
show: aString
This operation takes one argument which is a string to be displayed.
cr
This operation takes no argument and makes a carriage-return
One server interface providing a single operation:
broadcast: aString
This operation request the component to broadcast the message through the collection of clients interfaces.
Server Interface
Client Interface
Client Collection Interface
Optional Client Interface
