SOA with .NET and Windows Azure : Service Composition 101 (part 1)

In this section, we cover some fundamental aspects of composition in relation to service-orientation by briefly describing relevant principles and patterns.

Service-Orientation and Service Composition

A baseline requirement for achieving the strategic goals of service-oriented computing is that services must be inherently composable. As a means of realizing these goals, the service-orientation design paradigm is therefore naturally focused on enabling flexible composition.

This dynamic is illustrated in Figure 1, where we can see how the collective application of service-orientation principles share software programs into services that are essentially “composition-ready,” meaning that they are interoperable, compatible, and composable with other services as part of the same service inventory. The scope of this service inventory can vary, as long as it is meaningfully cross-silo .

Figure 1. Service A is a software program shaped into a unit of service-oriented logic by the application of service-orientation design principles. Service A is delivered within a service inventory that contains a collection of services to which service-orientation principles were also designed. The result is that Service A can participate initially in Composition X and, more importantly, can be pulled into additional service compositions, as required.

The key aspect of what is being shown in Figure 12.1 is not that services can be aggregated after delivery. All distributed systems are comprised of aggregated software programs. What is fundamentally distinct about how service-orientation positions services is that they are repeatedly composable, allowing for subsequent recomposition.

This is what lies at the core of realizing organizational agility as a primary goal of adopting service-oriented computing. By having a set of services (again, within the scope determined by the service inventory only) naturally interoperable and designed for participation in complex service compositions, we are able to fulfill new business requirements and automate new business processes by augmenting existing service compositions or creating new service compositions with reduced effort and expense. This target state is what leads to the Reduced IT Burden goal of service-oriented computing .

Service Composability

Among the eight service-orientation design principles, there is one that is specifically relevant to service composition design. The Service Composability principle is solely dedicated to shaping a service into an effective composition participant. All other principles support Service Composability in achieving this objective (Figure 2). In fact, as a regulatory principle, Service Composability is applied primarily by ensuring that the design goals of the other seven principles are realized to a sufficient extent.

Figure 2. A common objective of all service-orientation design principles is that they shape services in support of increasing composability potential.

Capability Composition and Capability Recomposition

Fundamental service identification and definition patterns can be assembled into an application sequence that forms a primitive service modeling process. However, those patterns result only in the separation of logic into individual functional contexts and capabilities.

The application of these fundamental patterns needs to be followed by patterns that reassemble the separated logic into aggregates. This is the purpose of Capability Composition  and Capability Recomposition (Figure 3).

Figure 3. Capability Composition is one of two patterns applied subsequent to the application of service identification and definition patterns. The relevance of the Capability Recomposition  pattern is explained in the following section.

Capability Composition

Capability Composition represents a pattern that is applied to assemble the decomposed service logic together into a specific service composition capable of solving a specific larger problem (Figure 4).

Figure 4. Although generally referred to as service composition, services that compose each other actually do so via their individual service capabilities, hence the name of this pattern.

The importance of this pattern, beyond forming the basis for the basic aggregation of service functionality, is that it reinforces fundamental patterns, such as Logic Centralization  and Service Normalization. It does so by preserving the functional boundaries established by service contexts in that it requires a service that needs access to logic outside of its context to access this logic via the composition of another service.

Capability Recomposition

As previously mentioned, the recomposition of services is a fundamental and distinctive goal of service-oriented computing. This pattern specifically addresses the repeated involvement of a service via the repeated composition of a service capability. The patterns relationship diagram shown in Figure 4 highlights how service identification and definition patterns, together with Capability Composition , essentially lead up to opportunities to apply Capability Recomposition].

A very important consideration here is that the application of Capability Recomposition  has a different purpose and different requirements than Capability Composition . As covered earlier, service-orientation design principles are geared specifically toward enabling the application of Capability Recomposition . And, as further shown in Figure .5, most other SOA design patterns solve their respective design problems in support of enabling the application of this pattern.