Overview of SOA features and the prospect of web extension services

Web

What is a service-oriented architecture (SOA)?

Service-Oriented Architecture (SOA) represents how you can use the big picture of WEB services. The WEB Service specification defines the details needed to implement the service and interact with them. However, service-oriented Architecture (SOA) is a way to build distributed systems, and distributed applications built with SOA can deliver functionality as a service to end users or build other services. A service-oriented architecture (SOA) can be based on WEB services, but it may instead be replaced with other technologies. When designing a distributed application with a service-oriented architecture (SOA), you can extend the use of WEB services from a simple client-server model to any complex system.

As a result, a single software asset becomes the basic building block for developing other applications. You can reduce system complexity by using a common interaction with new and legacy code (CBDI's Lawrence Wilkes joked that a service-oriented architecture (SOA) could represent "saving our assets (Save our Assets)". There is a standard way to represent these software assets and interact with them; now the focus has shifted to the assembly of applications based on these artifacts.

While the service-oriented Architecture (SOA) for business applications is discussed here, service-oriented Architecture (SOA) can also be used for other distributed systems, such as grid computing and advanced Web services specifications (for example, Web Services Distributed Management (ws-distributedmanagement), Web service trusts (Ws-trust), and UDDI.

What is a service?

In a service-oriented architecture (SOA), a service is an application function encapsulated as a reusable component for a business process. It provides information or simplifies the transformation of business data from an effective, consistent state to another state. The process used to implement a particular service is not important, as long as it responds to your commands and delivers high-quality services to your request.

By defining communication protocols, services can be invoked to emphasize interoperability and location transparency. A service behaves as a software component, because from the point of view of the service requester it looks like a self-contained function. In practice, however, the implementation of a service may include many steps that are performed on different computers within an enterprise or on computers owned by many business partners. In the case of packaged software, a service may be a component, or it may not be a component. As with similar objects, the requester application can see the service as a whole.

A WEB service is based on the invocation of a SOAP message that is described using the WSDL on a standard protocol such as HTTP. The best practice for using WEB services is to communicate with external business partners.

Loose coupling

The service requester's binding to the service provider should be loosely coupled to the service. This means that the service requester does not know the technical details of the provider's implementation, such as the programming language, the deployment platform, and so on. Service requesters often invoke operations through message invocation--requesting messages and responses--rather than using APIs and file formats.

This loose coupling allows the software at one end of the session to change without affecting the other end, provided that the message mode remains unchanged. In an extreme case, a service provider can replace a previously implemented implementation of legacy code (for example, COBOL) entirely with new Java-based code, without any impact on the service requester. This is true as long as the new code supports the same message pattern.

Explicitly defined interfaces

The service interaction must be clearly defined. The Web Service Description Language (Web Services Description language,wsdl) is a widely supported method for describing the details required by a service requester to bind to a service provider. The service description focuses on the actions that are used to interact with the following sections:

Service
The message that invokes the operation
Construct the details of such a message
Information about where to send messages to construct the processing details of such a message
The WSDL does not include any technical details of the service implementation. The service requester does not know or cares whether the service is written in Java code, C #, COBOL, or some other programming language. It can describe a SOAP invocation that uses HTTP. Because of its extension mechanism, it can also define other types of interaction, such as XML content submitted through JMS, direct method calls, calls handled by adapters that manage legacy code (CICS), and so on.

The generic definition of WSDL allows the development tool to create various types of interactions through the interface while hiding the details of how the service is invoked by the application code. For example, if a service is exposed in a variety of interaction types, the Web service invocation framework (Web services invocation framework,wsif) uses this capability by allowing the runtime to decide on the best way to invoke high-quality services.

Non-state Service design

A service should be a stand-alone, self-contained request that, when implemented, does not require information or status from one request to another. Services should not be dependent on the context and state of other services. When dependencies are needed, they are best defined as generic business processes, functions, and data models, rather than implementing artifacts (such as session keys). Of course, the requester application requires a persistent state between service invocations, but this should not be separated from the service provider.

Here is an example of an error method that defines a session:
Requester: "What is Bruce's checking account balance?"
Provider: "$x"
Requester: "And what is he credit limit?"
Provider: "$y"

The provider is asked to remember the Bruce's account number between requests, which introduces complexity in the service implementation. The stateless service design will redefine the session as follows:
Requester: "What is Bruce's checking account balance?"
Provider: "$x"
Requester: "What is Bruce's credit limit?"
Provider: "$y"

Granularity of service

The granularity of operation is an important design point. Coarse-grained interfaces are recommended for external consumption, while fine-grained interfaces may be used within the enterprise. A coarse-grained interface may be a complete processing of a particular service, such as Submitpurchaseorder, where the message includes all the business information required to define the purchase order. Fine-grained interfaces may have different operations for the following methods: Createnewpurchaseorder, Setshippingaddress, AddItem, and so on.

Although fine-grained interfaces provide more flexibility for requester applications, it also means that the pattern of interaction may vary depending on the service requester. This may make support for service providers more difficult. The coarse-grained interface guarantees that service requesters will use the service in a consistent manner. Service-Oriented Architecture (SOA) does not require the use of coarse-grained interfaces, but it is recommended as a best practice for external integration. Service choreography can be used to create coarse-grained interfaces that run business processes made up of fine-grained operations.

Quality of service issues to consider

Service-Oriented Architecture (SOA) design will span computer systems and may also span enterprise boundaries. You have to consider security features and requirements when using the Internet, and how to link the secure domain of a partner. Internet protocols are not designed for reliability (guaranteed delivery and delivery order), but you have to make sure that the message is committed and processed once. When this is not possible, the requester must know that the request has not been processed.

For example, you might want to consider the metrics, reliability, and response times of the services you deploy in order to ensure that they are within the scope of the commitment. When you design a system that uses services from other business partners, you have to consider service-oriented management to collaborate on managing services between partners.