Overview
The design of the Tideland Lightweight Application Server is concentrated around a broker which is the central element for the management of components and asynchronous message dispatching. The access to the LAS per session (e.g. in a web application), application, or process inside the system is done via the context.
Core
LasContext
The class LasContext is the entry point for applications to the LAS. It stores the client id, which is importand in a multi-client system. A second importand variable is the connection to the LasBroker. This connection is used for the sending of LasMessages to the broker. Additionally the context is used for the access to the configured application components by id.
The context also stores key-value-pairs. This can be used for the storrage of user informations or database connections.
LasBroker
The LasBroker is responsible for the management of the components and the dispatching of messages to the LasCconnectors in the order of their priority. The messages are queued and passed to the connectors whose filter expressions show an interest for a message.
LasMessage
The LAS provides an asynchronous message processing. Messages are objects with header informations and a content object. The LasConnectors contain filter blocks which evaluate the message. If those return true, e.g. due to the message type, the verb or the noun (all parts of the header), the message will be processed.
LasConnector
The connector is used for two purposes: First the contexts also contain a connector to send messages to the broker. Second the connectors are used to attach actions to the broker. Those actions are processed if the filter block of a connector returns true when evaluating a message. So a publish/subscribe pattern is realized and multiple subscribers can process the same message, e.g. a special handling of problem reports based on the problem priority.
Typically services are attached to the connectors so that they implement the service operations. One base service implementation provides a dynamic dispatching of message verb and noun to a method call. Each message contains the context for the access of components, sending messages, and returning answers.
Application Specific Classes
Services
Each class can be used as a service. It just has to be attached to the connector inside the action block, e.g.
(LasConnector on: aBroker) action: [:msg | myService processMessage: msg]
Messages are called in parallel processes with different messages and contexts. So they should have no state.
Components
Components are simple Smalltalk classes. They don't need any special methods, but some conventions are used. First if the class understands context: aContext the current context is set. But this only makes sense for context components. Second all setters in the protocol las are enumerated. The component with the name of the setter minus the colon is retrieved from the context and set. So if the class understands authentication: anAuthentication in the protocol las the component with the id #authentication will be retrieved and set.
This way of instantiation is called inversion of control pattern.