Much has been written about the decomposition of software designs into components or subsystems. Much has also been
written about the need to understand the deployment topology required by an application early in its lifecycle so that
correct architectural decisions can be made. However, there are very few mechanisms identified or used today to
help logically partition a system during architectural analysis, so that decisions regarding the logical
topology of a solution and the constraints imposed by non-functional requirements can easily be addressed at the model
level before detailed design and implementation work products are generated. The following discussion outlines a
set of simple model elements that support this reasoning. While they were developed with service-oriented solutions in
mind, these techniques are applicable to any software architecture modeling.
The following definitions are taken from the Rational Unified Process (RUP) glossary and contrast the notions of layers
and partitions. Interestingly enough, the term tier, while common in describing the logical architecture of a
solution, does not appear in the RUP glossary.
-
Layer
-
(1) A specific way of grouping packages in a model at the same level of abstraction.
-
(2) The organization of classifiers or packages at the same level of abstraction. A layer
represents a horizontal slice through an architecture, whereas a partition represents a vertical slice.
-
Partition
-
(1) activity graphs: A portion of an activity graph that organizes the responsibilities for actions. See
also: swimlane.
-
(2) architecture: A subset of classifiers or packages at the same level of abstraction. A partition
represents a vertical slice through an architecture, whereas a layer represents a horizontal slice.
So, a partition contains a set of elements representing some part of the architecture, but how does the Software
Architect slice a model? The answer is deceptively simple: Partitions and layers are organizational constructs; at
an architectural level they only represent logical organization. So, what aspects of the organization of a solution do
you want to represent? For example, if the model view you are developing is concerned with security, then you might
want to represent Trust Zones [JHN05].
What can a partition represent?
As we said above, a partition can be used to represent any particular organization concerns the
architect wishes to focus on. The following are common views that are constructed in a model. One key aspect
of partitions is that they do not imply ownership/containment, so a service can appear in multiple partitions
simultaneously.
Logical Solution Organization; in this case the partitions represent the logical clustering of elements in a
given solution. For example, in a business application we might use partitions to represent the separation into
user interaction services, business services, and infrastructure services. Such a view corresponds more to the use
of layers in RUP to describe tiers of an application. However, as services are not easily layered in the same way
as a component or object-based solution, we use partitions. For more information on these service classifications,
see the Concept: Service Portfolio.
The following figures are partitionings used to represent logical structure of a solution.
Figure 1. User Interaction Services

Figure 2. Business Services
Figure 3. Infrastructure Services
High-Level Physical Distribution; in this case, partitions can be used to denote local versus
remote services, at least when physical distance imposes constraints on the architecture. For example, noting that
the customer, account, and order services are hosted in our primary data center and that the Electronic Data
Interchange (EDI) gateway is hosted in a secondary data center is important when we also discover that the
bandwidth connection between these centers is managed and we have to carefully control communication between these
partitions.
Business Application/Ownership Boundaries; in this case, partitions are used to represent ownership of services
by a business area or by an application area. For example, we might denote that certain services are "owned" by Human
Resources, some by Sales, and some by Marketing. Now, while this is not an architectural concern, most projects have to
deal with aspects that do not involve technology or architecture, but the social and political aspects of the
organization. Partitions, in this respect, enable us to see how the interaction between services crosses such
boundaries and might impact the development process by requiring stakeholder support for cross-organizational change.
In this case, business functional areas would form the categories for this model.
Business Process Boundaries; in this case, we represent end-to-end process areas with partitions, in effect
grouping services by the processes they support. Figure 4 contrasts the process view (shaded) with
the business systems view represented as the vertical bars. It is important in many cases to relate these two views
of services already deployed and services planned by a project.
Figure 4. Process view of the organization vs. business organization view
To understand this relationship between the vertical business area and the cross-business processes,
it is important to understand how each business area provides services to the processes that actually run the
business. In respect to our example, this view regroups the services we identified earlier into new partitions as
shown in the following two figures: Alternative services grouping, aligned by business
area.
Figure 5. Order Management
Figure 6. CRM
Partitions in the Service
Model
In the Service Model, a SoaML Participant can be used to model partitions. A partition can
contain not only instances of service Participants, but also instances of other partitions, and so can be further
decomposed where appropriate. A service partition can also specify one or more ServicePoints. In the
context of a partition, these ServicePoints often are known as service gateways. These gateways are themselves services
specifying the interface to a partition.
The order management process area is accessed by the same interface as is the order entry service provider in
the diagram above. We term this promoting the interface from the service out to the partition. Figure 7 depicts
this and shows how the order entry service provider communicates with the other services in the partition.
Figure 7. Promoting a service interface out to the partition
The partition's service gateway has the ability to mediate communication bindings between clients on the
outside of a partition and services on the inside. This enables services to deal only with certain protocol
bindings within a partition, for example to use a higher performance or more secure protocol within the boundaries and
to expose certain capabilities to clients over a different protocol. For more information see the concept Service Mediation.
As the partitions are based on UML 2.0 Composite Structures, there is no "containment" relationship between the
partition and the services. It is possible, as we have shown above, to represent the same services in multiple
partitions or views. If this flexibility is tied to the capability of service gateways, the software architect and
designer can cluster services in logical groupings and allow service gateways to expose only relevant interfaces to
clients.
A strict partition is a partition where all services within the partition are accessed by clients/services outside the
partition through service gateways. This implies that the service partition has its own set of interfaces. As
such, it can be viewed as a logical higher-level service provider. This is particularly useful for partitions that
represent either business application boundaries or business process boundaries. This representation enables
designers to specify the interfaces the process exposes to the rest of the business and to designate which of
the services that support the process area are being made publicly available. The order-management partition above is a
strict partition, but the concept of "strictness" can only be assessed by evaluating a partition. It is not a
property of the model element itself.
In the example below, the partition on the left can be considered strict because the client (outside the
partition) can only communicate with the order entry provider (within the partition) via a gateway. The partition
shown on the right hand side of the diagram cannot be considered as a strict partition, as the client communicates
directly with the order entry provider inside the partition.
Figure 8. A strict partition
It is important to realize that modeling of strict partitions, even the use of gateways at all, is optional and
should be considered simply as a tool that allows for the modeling of explicit communications between partitions
(whatever they themselves represent). For many purposes the additional overhead might not be warranted.
|