Design Considerations for a Service Component - Utility Services

In an SOA system, a service component which implements a service, is similar to a small application; it has to do many of the same tasks an application does, such as security enforcement, data management and service management. Service components may therefore, like applications, call on services to complete some tasks. For example, a service component can call an audit service, in order to create an audit record.

These types of services are usually called utility services. Here is a partial list of utility service types:

• Authentication: Verify the credentials provided by the requesting agent
• Identity: Use the identity of the requesting agent
• Personalization: Retrieve, update and apply preferences of the requesting agent or person
• Access control: Control access to resources based on policy
• Encryption: Encrypt/decrypt and sign messages; manage keys
• Provisioning: Grant or remove access to a resource or service
  
• Master data management: Access and update master entities (customer, product, account, etc)
• Rule execution: Execute business rules
• •
  •Auditing: Record audit events
• Logging: Record events useful for debugging and system recovery
• Service management: Set and manage service levels based on policy
• Error management & reporting: Handle and report errors
• System monitoring and notification: Monitor service and raise notifications when thresholds exceeded

Some utility services, such as access control, can be fully or partially provided by the SOA runtime. However, in many cases utility services must be called directly by a service component. If the service is distributed and uses a web service implementation then qualities of service such as reliability and performance, tend to decrease. In object oriented systems, utility services are provided by in-memory objects or local components, so this is not an issue. In the SOA era, we can still use local libraries, to accomplish a task but its not as flexible as using a service and introduces platform coupling.

There is no easy solution to this problem; in a sense SOA has just pushed some of these problems down a level. For now, I suggest building two versions of each service: a fully distributed service and a local component which can be loaded directly into memory by a service component. Yes, this is not fully satisfactory, but it is at least one step forward.