Characteristics Description Benefits, applicability, and notes
Loose coupling Service providers and consumers can be developed independently using well-defined interfaces.

Service implementers can change interface, data, or message versions in the service without impacting consumers.
Loose coupling removes the need for tight control of both ends of systems. Each system can be independently managed for performance, scalability, and high availability.

It does not remove any runtime dependencies. It could divide the dependencies over a number of service providers, but if the runtime system needs 24x7 availability and 50,000 throughputs per second, then these are requirements on the service providers and must be met.

Implementation changes are hidden.

Loose coupling gives providers and consumers independence, but requires standards-based interfaces and an intermediary to actively manage and broker requests between end systems.
Industry standards-based True industry standards are endorsed by technology leaders such BEA, IBM, Microsoft, Sun, Oracle, W3C, and Oasis. SOA is widely accepted because it can be implemented using standards-based technologies.

Prevents the need to have proprietary clients.
Using standards-based technologies breaks vendor lock-in and facilitates best-of-breed combination of vendor products.

The concept of loosely coupled layers depends upon broad support for standards both internally and externally.
Reusable services As services are published in a directory and available over a network, they become more easily discoverable and reusable. If a service cannot be reused, it may not require a service interface at all.

Services can be reused by recombining them for different purposes.
Reuse of services eliminates duplicate development efforts and promotes consistency in implementation.

Reuse of services is easier to accomplish than component or class reuse, which have been tried without much success in the past.
Synchronous service calls (RPC style) In a synchronous service call, the caller makes the call, passes the required parameters, blocks, and waits for the response. Synchronous service calls provide immediate response to a request if the service provider is available.

Synchronous services are essential for applications requiring real-time response, for example, Portal or Query.
Asynchronous service calls (document style) In asynchronous service calls, the caller posts a message with full context to a messaging service that delivers it to the recipient. The recipient processes the message and returns the response to the caller via the message bus. The caller does not block while the message is being processed. With the use of coarse-grained messages and a messaging service, service requests can be queued and processed at the optimum system speed. This approach provides high scalability because the messaging system can queue as many requests as its queue depth allows (tunable). Callers do not hold network connections for the processing duration, and because callers don't block, they are not negatively impacted by processing delays and problems in the execution of an asynchronous service.

This implementation assumes support for callbacks, which is not part of Web services standards.
Non-intrusive development (developing services by using existing software components) Existing software components don't need to be modified to expose their functionality as services. Services are developed or generated using the interface definition of a component. Eliminates the need for modifying, testing, and maintaining existing software.

With composite services, the functionality from existing investments can be reused and recombined to create new value for the enterprise.

An example is creating WebLogic Workshop controls for existing EJBs.
Policy management When shared services are used in applications, the rules specific to each application are externalized as policies.

Policies must be managed and applied for each service at design and run time.
Policy-based computing promotes the creation of generic reusable services. As customization of services for specific applications is externalized, application implementation changes are minimized.

An organization's operations and support group, rather than the development group, typically enforces policies. Without the use of policies, application developers and operations and support groups have to work together during development time to implement and test policies. Using policies allows developers to focus on application logic while the operations and support group focuses on rules.
Data access services Data access, integration, transformation, and reuse services. Hides data source complexity and enforces consistency, integrity, and security across data sources.
Composite services Composite services combine new and existing application logic and transactions. Leverages existing IT investments. Suitable for green-field and legacy implementations.

Assembly or orchestration products simplify the integration of heterogeneous systems.
Shared or enterprise infrastructure services Common services used by all applications built using SOA are called shared infrastructure services. Using a shared infrastructure to provide common services prevents each application from building similar services. Using shared infrastructure services provides consistency and allows a single point of administration.

Other shared services, such as security-related services, can be built by exposing existing products as services.
Fine-grained services A fine-grained service implements minimum functionality and consumes and returns a minimum amount of data.

Fine-grained services can be implemented using Web services, or distributed objects using RMI, .Net, or CORBA.
Fine-grained services have the benefit of imposing strict security and access policies at a granular level.

Implementation and unit testing are simple and independent.
Coarse-grained services Coarse-grained services implement more functionality than fine-grained services, and consume different amounts of structured data or messages. They return similar data or messages, possibly with embedded context. Coarse-grained services do not require multiple calls over the network to provide meaningful business functionality.

Table 2 An SOA-based solution requires a certain set of characteristics from an SOA infrastructure. Here are some typical SOA characteristics.