Publications :: Books :: Server Component Patterns :: Gallery

1 Core Infrastructure Elements

		Component Decompose the functionality of your application into several distinct COMPONENTS, making each COMPONENT responsible for providing a specific self-reliant part of the overall functionality. Let every COMPONENT implement its responsibilities in full without introducing strong dependencies to other COMPONENTS. Compose the complete application by assembling the required functionality from these loosely-coupled COMPONENTS.
		Container Provide an execution environment that is responsible for adding the technical concerns to the COMPONENTS. This environment is generally called CONTAINER. Conceptually, it wraps the COMPONENTS, thus giving clients the illusion of tightly-integrated functional and technical concerns. To implement these technical concerns in a reusable manner, a CONTAINER uses frameworks and other generic techniques such as code generation.
		Service Component Encapsulate processes and micro-workflows as SERVICE COMPONENTS. SERVICE COMPONENTS are stateless, which means they cannot carry state changes from one invocation to another. This allows the CONTAINER to implement this kind of COMPONENT efficiently. This comes at the price that all operations have to be selfsufficient: they must implement a specific process and then terminate.
		Entity Component Encapsulate business entity types as ENTITY COMPONENTS. An ENTITY COMPONENT instance represents a particular business entity. Its state is persistent in a store such as a database. Each instance has a unique identifier. The CONTAINER will coordinate concurrent access to a specific instance and ensure that consistency is preserved.
		Session Component Provide a third kind of COMPONENT, the SESSION COMPONENT. SESSION COMPONENTS do have client-specific state, but this state is not persistent. No concurrency is allowed, thus no synchronization overhead is implied. The CONTAINER ensures that resource usage is kept reasonable even for large numbers of clients.

2 Component Implementation Building Blocks

		Component Interface Provide a COMPONENT INTERFACE that declares all the operations provided by a COMPONENT, together with their signatures and, ideally, their semantics. Use this interfaces as a contract between the client and the COMPONENT. Let clients access a COMPONENT only through its interface.
		Component Implementation Use a COMPONENT IMPLEMENTATION that is separate from the COMPONENT INTERFACE. This provides implementations for all the required operations: business, LIFECYCLE CALLBACK, and COMPONENT HOME. These implementations can be implemented in one software entity, or alternatively, distinct entities can be used to implement the different kinds of operations.
		Implementation Restrictions Impose IMPLEMENTATION RESTRICTIONS on the COMPONENT IMPLEMENTATION. Limit the programmer’s freedom over what they can do in the COMPONENT IMPLEMENTATION by preventing them from using language or API features that might interfere with the CONTAINER.
		Lifecycle Callback Require a COMPONENT IMPLEMENTATION to implement a set of welldefined LIFECYCLE CALLBACK operations. Each of these operations is invoked by the CONTAINER at a well-defined point during the lifecycle of an instance, to make the instance do the things the CONTAINER expects. To make this work, the COMPONENT IMPLEMENTATION has to provide a correct implementation of these operations.
		Annotations Provide a means for the COMPONENT developer to annotate the COMPONENTS with the technical concerns. Such ANNOTATIONS are a part of the COMPONENT, but separate from the COMPONENT IMPLEMENTATION and the COMPONENT INTERFACE. The ANNOTATIONS specify how the CONTAINER should apply the technical concerns for the COMPONENT. ANNOTATIONS are not program code, they are a high-level specification. It is the CONTAINER’s job to decide on the concrete implementation.

3 Container Implementation Basics

		Virtual Instance Give clients the illusion that every COMPONENT instance is always available by using VIRTUAL INSTANCES. This requires logical and physical COMPONENT identities to be distinguished. A physical COMPONENT instance and its logical identity – the thing the physical instance represents – must be separated. When a client invokes an operation on a logical instance, the CONTAINER has to make sure that a suitable physical instance is available to handle the request.
		Instance Pooling Create a pool of physical COMPONENT instances in the CONTAINER. When a VIRTUAL INSTANCE is accessed by a client, assign one of the pooled instances to the VIRTUAL INSTANCE to handle the request. Return the instance to the pool after handling the request. Use LIFECYCLE CALLBACKS to notify a pooled instance of upcoming state changes. The implementation of the LIFECYCLE CALLBACK operations has to take all measures to make sure it represents the VIRTUAL INSTANCE correctly.
		Passivation Allow the CONTAINER to remove COMPONENT instances temporarily from memory when they are not accessed for a specific period. The state of such a passivated COMPONENT must be stored persistently. When the instance is accessed again, the state must be reloaded. Make sure that this works transparently from the COMPONENT developer’s viewpoint.
		Component Proxy Provide a proxy for the physical COMPONENT instances. Clients never have a reference to the physical component instance, they only talk to its proxy. The COMPONENT PROXY is responsible for implementing INSTANCE POOLING or PASSIVATION. It takes care of the enforcement of the technical requirements specified in the ANNOTATIONS. To increase performance, one proxy is usually responsible for several logical COMPONENT instances.
		Glue-Code Layer Use a layer of generated code as an adapter between the generic parts of the CONTAINER and the specific COMPONENT IMPLEMENTATION. This layer adapts the generic CONTAINER to a specific COMPONENT. Generate a specific GLUE-CODE LAYER for each COMPONENT running in the CONTAINER. In particular, the COMPONENT PROXY is part of the GLUE-CODE LAYER.

4 A Component and its Environment

		Component Context Let the CONTAINER provide a COMPONENT CONTEXT to each COMPONENT instance. This context object’s interface provides operations for accessing resources, security information, the current transaction or instance-specific information about the COMPONENT instance itself. It can also include the possibility of accessing other parts of the COMPONENT’s environment, such as NAMING or the COMPONENT-LOCAL NAMING CONTEXT.
		Naming Provide a central NAMING service that maps structured names to resource references. NAMING can be used uniformly to look up any kind of COMPONENT or resource reference. It can be accessed by clients and by COMPONENT IMPLEMENTATIONS using commonlyknown object references provided by the APPLICATION SERVER or the COMPONENT BUS.
		Component-Local Naming Context Provide a COMPONENT with its own local NAMING context. The COMPONENT IMPLEMENTATION accesses only this local name. When a COMPONENT is installed in a CONTAINER in a specific environment (APPLICATION SERVER), map the names in the local context to the names of the actual resources in the global NAMING system.
		Managed Resource Let the CONTAINER manage resources for the COMPONENTS. This includes pooling of resource instances for faster acquisition by the COMPONENTS. All resources available to COMPONENTS have to be registered with the CONTAINER and published in the CONTAINER’s NAMING system. COMPONENTS access resource factories through the COMPONENT-LOCAL NAMING CONTEXT.
		Pluggable Resources Define resource adapters that allow any kind of resource to be plugged into the APPLICATION SERVER. Define a generic interface between the resource adapter and the APPLICATION SERVER that defines operations that allow the APPLICATION SERVER to build and manage pools of connections to the integrated system, and to integrate with the CONTAINER’s technical concerns such as security and transaction coordination. As with MANAGED RESOURCES, these also provide a resource factory available through NAMING for use by COMPONENTS to obtain connections.
		Configuration Parameters Allow the COMPONENT to access configuration parameters that are defined for the COMPONENT during COMPONENT INSTALLATION. Such parameters are usually name-value pairs, both of a string type. Make this information accessible from within the COMPONENT IMPLEMENTATION, for example by using the COMPONENTLOCAL NAMING CONTEXT or the COMPONENT CONTEXT.
		Required Interfaces Allow a COMPONENT to specify which other COMPONENT INTERFACES it uses to perform its task. Either include it in the COMPONENT INTERFACE or add it to the ANNOTATIONS. Note that such dependencies can depend semantically on a COMPONENT’s IMPLEMENTATION, not just on its abstract specification.

5 Identifying and Managing Instances

		Component Home For each COMPONENT, provide a COMPONENT HOME that serves as an interface for clients to manage instances of the respective COMPONENT. Depending on the kind of COMPONENT, the COMPONENT HOME provides different operations for creating and locating instances.
		Primary Key Provide a PRIMARY KEY that uniquely identifies an ENTITY COMPONENT instance. The class used as the PRIMARY KEY should be userdefinable. Make sure that objects of this class can be passed by value and that the PRIMARY KEY can be easily stored in persistent storage.
		Handle Provide HANDLES for each COMPONENT. A HANDLE created by a specific COMPONENT instance knows how to re-acquire the reference to the instance from which it was created. HANDLES can be passed by value or stored persistently. The actual implementation of a HANDLE is the responsibility of the CONTAINER.

6 Remote Access to Components

		Component Bus Access COMPONENTS only via a COMPONENT BUS, a generic communication infrastructure for remote and local COMPONENT access. Because the COMPONENT BUS is integrated with the CONTAINER, it can provide efficient access to a large number of COMPONENT instances. Because it knows the location of the caller and the invocation target, it can optimize local invocations efficiently. The COMPONENT BUS hides the underlying low-level transport protocol, its semantics and its QoS attributes. Its configuration is done with the help of ANNOTATIONS.
		Invocation Context Include an INVOCATION CONTEXT with each operation invocation. This context contains all the information necessary for the CONTAINER to handle the technical requirements. The concrete structure of this context depends on the CONTAINER. It is the job of the COMPONENT BUS to transport this additional data. The CLIENTSIDE PROXY must insert the data on the client side.
		Client-Side Proxy Provide a CLIENT-SIDE PROXY for remote COMPONENTS that implements the respective COMPONENT INTERFACE and accepts local method invocations. The proxy forwards the invocation data to the COMPONENT BUS and also supplies the necessary data for the INVOCATION CONTEXT.
		Client Library Create a CLIENT LIBRARY upon COMPONENT INSTALLATION on the server. Most importantly, this contains the CLIENT-SIDE PROXY that is the placeholder for any remote COMPONENTS in the client processes. It also contains any other parametrization or initialization parameters that are necessary for the client to access the CONTAINER and APPLICATION SERVER remotely, as well as a suitable implementation of the COMPONENT BUS.
		Client Reference Cooperation Make sure that the clients cooperate in distributed garbage collection. This can be implemented in different ways, for example heartbeats, pinging, or leases (see below). In all cases the CONTAINER has a means of determining when it can destroy the instance. Each strategy has different consequences in the case of unreliable networks and clients.

7 More Container Implementation

		System Errors Define two different kinds of error: application errors and system errors. All operations on COMPONENTS can cause specific system errors at any time. System errors can also be raised by the CONTAINER without the COMPONENT IMPLEMENTATION’s involvement or knowledge. Ensure that application errors are handled by the client and the CONTAINER does not have to be concerned with them. System errors should be handled by the CONTAINER and optionally forwarded to the client.
		Component Introspection Provide information about the structure of a COMPONENT to the CONTAINER and to support tools. If the underlying language supports reflection, you can use this mechanism directly. Otherwise, you might need to generate the necessary information from the source code. In any case, make sure that this meta-information is always consistent with the actual COMPONENT.
		Implementation Plugin Provide a means to plug in code generators into your CONTAINER for certain aspects of a COMPONENT IMPLEMENTATION. Developers might have to write additional specifications to allow the tool to generate such code correctly. The code is generated as part of the GLUE CODE LAYER. Provide a standardized interface for these IMPLEMENTATION PLUG-INS.

8 Component Deployment

		Component Installation Provide a well-defined installation procedure. This procedure handles all the artifacts that make up a COMPONENT. During this procedure the CONTAINER can do everything necessary to host the COMPONENT successfully.
		Component Package Define a COMPONENT PACKAGE file format and structure. This archive contains all the artifacts of a COMPONENT. The package is used for distribution and upon COMPONENT INSTALLATION. The COMPONENT is supplied to the target CONTAINER in such an archive.
		Assembly Package Provide an ASSEMBLY PACKAGE that contains all the COMPONENT PACKAGES that make up an application. Specify the relationships between the COMPONENTS of the application and include common configuration data.
		Application Server Provide an APPLICATION SERVER that serves as a shell for the different CONTAINERS, the MANAGED RESOURCES and additional, non-COMPONENT services. All these services should run in one process. An APPLICATION SERVER usually provides a GUI-based configuration and monitoring tool.