1.7 Enterprise services

A number of enterprise services are often layered on top of component models. These services automate some of the tasks people often face in enterprise settings, typically by making it possible to replace manually written, and often error-prone, imperative code with declarative attributes. Enterprise computing often implies that services run on different machines, which benefits from the support for location-transparent invocations often provided by component models.

Component model implementations used in the enterprise typically come bundled with standardized servers that host components, known as application servers. Having a standard server implementation helps developers focus on writing domain-specific code. An application server is used to encapsulate business logic, and typically sits between a user-facing front-end, such as a web page or a standard application, and a persistence layer in the form of a database server. An application server is a complete server, but needs business logic in the form of components to be plugged in before it can do anything useful.

This is a list of some enterprise services typically provided by component models intended for use in the enterprise:

• Transaction processing. Modern database servers use transactions to group a set of database operations that must be either committed as a group, or not at all, in order to maintain data integrity. Component models automatically manage transactions if declarative attributes to that effect are set. A transaction is committed if a set of operations complete successfully, and is rolled back if errors are signaled.

• Loosely coupled events. Traditionally, event consumers subscribe to events by communicating directly with the event producer. This feature decouples consumers and producers by introducing an event service, which enables features such as efficient multicasting and filtering. Events can often be subscribed to by setting a declarative attribute.

• Deferred processing. Some requests need not be performed right away and can be postponed for later. If the component which is to perform the service is not available, the request is put in a queue. A component may be unavailable for a variety of reasons, such as when the network is unreachable or the computer on which the component runs is powered off. This feature may also be used to schedule jobs to execute during off-peak periods, and to balance the load across several machines.

• Security. Certain services may only be available to components running as privileged users. The security model of a component model can help enforce security policies by preventing access to certain services. Access may be barred to certain components, implementations of certain interfaces, or even to specific operations.

• Just-in-time activation. Component models normally strive to keep instances alive for as long as there are active references to them. This feature helps conserve resources on a server by destroying instances that are referenced, and transparently instantiating them anew when they are accessed.

• Synchronization. Objects that are not reentrant should not allow multiple simultaneous threads of execution. Such objects can be tagged with a declarative attribute that enables a component model implementation to bar concurrent access.

• Object pooling. Keeping instantiated objects in a pool for later reuse can significantly boost performance. A pool contains instantiated objects, ready to be used. When an active object is no longer used, it can be put back into the pool for later use. Declarative attributes can typically be used to configure certain aspects of the pool, such as its maximum size.