Service Oriented Framework For Analysis

SOA Patterns

REST Patterns

Content Negotiation

Description: This pattern supports alternative resource representations, e.g., in json, xml, pdf, etc. so that the service consuming becomes more flexible with high reusability. Servers can provide resources in any standard format requested by the clients. This pattern is applied via standard HTTP media types and adhere to service loose coupling principle. If not applied at all, this turns into Ignoring MIME Types antipattern.

Heuristic of Content Negotiation REST pattern:


End-point Redirection

Description: The redirection feature over the Web is supported by this pattern, which also plays a role as the means of service composition. To redirect clients, servers send a new location to follow with one of the status code among 301, 302, 307, or 308. The main benefit of this pattern is, an alternative service remains active even if the requested service end-point is not sound.

Heuristic of End-point Redirection REST pattern:


Entity Linking

Description: This pattern enables runtime communication via links provided by the server in the response body or via Location: in the response header. By using hyper-links, the servers and clients can be loosely coupled, and the clients can automatically find the related entities at runtime. If not properly applied, this pattern turns into Forgetting Hypermedia antipattern.

Heuristic of Entity Linking REST pattern:


Entity Endpoint

Description: Services with single end-points are too coarse-grained. Usually, a client requires at least two identifiers: (1) a global for the service itself and (2) a local for the resource or entity managed by the service. By applying this pattern, i.e., using multiple end-points, each entity (or resource) of the incorporating service can be uniquely identified and addressed globally.

Heuristic of Entity Endpoint REST pattern:


Response Caching

Description: Response caching is a good practice to avoid sending duplicate requests and responses by caching all response messages in the local client machine. In opposed to Ignoring Caching antipattern, the Cache-Control: is set to any value other than no-cache and no-store, or an ETag is used along with the status code 304.

Heuristic of Response Caching REST pattern:




SCA (Service Component Architecture) Patterns

Basic Service Pattern

When dealing with SOA pattern specification and detection, we want to specify the best fundamental characteristics every system designer or architect should take into account. Several principles, some of which are described in SOA Patterns, have to be considered for service design. Components reusability (SR) as well as high cohesion (COH) are common requirements in the design of general systems such as OO systems. The dynamic nature of SOA systems introduces new non-functional requirements such as high availability (A) or low response time (RT). These metrics are combined in the rule card shown on Figure a for the specification of this Basic Service pattern.

Facade Pattern

A Facade, as illustrated in Figure 5, is used in SOA systems to get a higher abstraction level between the provider and the consumer layers. Fowler and Erl describe the pattern respectively as Remote Facade, Decoupled Contract or Service Decomposition and give as example using it to wrap legacy systems. This pattern is similar to the Facade in OO systems because it hides imple- mentation details such as nested compositions and calls. It also provides loosely coupled relationships with consumer services and let the implementation evolve independently, without breaking the client contract. Using this pattern, it is possible to decompose SOA systems following the principle of separation of concerns. It will thus be easier to reuse the different layers in other systems. A Facade can be responsible for orchestration, and can describe how composition of subsequent services can fulfill the client requirements. Given that the Facade acts as a front layer to several clients, we characterize its response time (RT) as high. Such a pattern is defined to hide implementation details from many ser- vices. Thus, its incoming outgoing calling ratio (NIC/NOC) is low because for one incoming call, the components tends to execute multiple outgoing calls. Fi- nally, we assume that such a service has a high delegation ratio (DR) because it does not provide business logic directly but, instead, delegates to other services. Figure b shows the rule card specification for the Facade pattern.



Proxy Pattern

The Proxy pattern, represented in Figure 6, is another well-known design pattern from OO systems, that adds an additional indirection level between the client and the invoked service. Its objective differs from a Facade because it can, for example, add new non-functional behaviors, which can cover security con- cerns such as confidentiality, integrity or logging execution calls for accountabil- ity goals. Different kinds of Proxy patterns exist, such as Service Interceptor or Service Perimeter Guard, and they could all be specified with several dis- tinct rule cards. Instead, we choose to specify a generic version of this pattern with the following characteristics. The proportion between incoming and out- going calls (NIC/NOC) has to be equal to one because it acts only as a relay. Moreover, this relay property implies that incoming and outgoing method sig- natures have to be the same. The fact that the Proxy pattern generally adds non-functional requirements to SOA systems also means that it can be involved in several scenarios. Thus, it has a high service reuse (SR) compared to other services. Figure c shows its underlying rule card.



Adapter Pattern

The Adapter pattern is also close to the Adapter as found in OO systems. Its goal is to adapt the calls between the destination service and the clients. The integration of legacy systems into a SOA system often requires adaptations to perform type transformations and preserve the functionality of the legacy systems. Daigneau gives the example of a Datasource Adapter pattern as a solution that provides data access to specific different platforms. In general, the number of incoming and outgoing calls are identical, thus the ratio (NIC/NOC) is equal to one. Given the fact this pattern adapts specific client calls, we can infer a high proportion of signature change (PSC) between incoming and outgoing calls. This characteristic makes the Adapter differ from the Proxy, which preserves the method signatures and simply relays calls. Figure d shows the Adapter pattern rule card.



Router Pattern

The Router pattern is similar to a network router that forwards packets according to different paths. A SOA Router distributes incoming calls to various destinations based on different criteria, which can be either the client identity or the call parameters. Some smart routers either de- tect paths on dynamic metrics such as availability or previous calls history and forward calls to the best matching service. The main criterion to consider is a change of outgoing paths for a specific incoming call, so a high proportion in path changes (POPC) can be significant. It may be interesting to see if some specific clients use specific paths and then make the correlation with incoming parameters. Figure e shows the Router pattern rule card.

SOA Patterns Rule Cards

Each SOA pattern specified in SODOP has been described with a domain specific language.
The five patterns are described on the folowing image:

[top]



Logo Logo