Government of Canada Service Oriented Architecture Series - Primer

• Previous Page
• Table of Contents
• Next Page

4.0 - The Three Layers of the GC SOA

The GC SOA specifies three distinct layers within an overall business context (the virtual fourth layer). These three layers represent an industry-recognized approach to the layering of any IT architecture. The main alteration to the broader SOA models commonly seen in the industry today is the encapsulation and naming of the layers such that each layer's name reflects what it comprises and the motivation for encapsulating it.

Figure 3 - The Three layers of the GC SOA

4.1 - Layering Benefits

The GC SOA architecture is broken down into these layers in recognition of the intuitive and well-known reasons noted below.

• It is easier to understand one layer at a time as a coherent whole rather than grasping the complexity of the entire architecture from top to bottom.
• Dependencies between layers are minimized and interconnections between entities are reduced to a manageable set.
• Typically standards are introduced to layer interfaces so that the maximum number of consumers can utilize the services provided by the supporting layer. The Open Systems Interconnection reference model is a widely used example of just such a layering.
• As one moves up the layers (or stack if you will), the level of abstraction increases hiding the details and complexity thereby allowing one to conceptualize and solve higher order business problems.
• With standards firmly in place, layers can be replaced or interchanged with other layer providers. For example in the OSI model, should a layer be a TCP/IP layer, there are multiple TCP/IP stack providers one can choose from.

Lastly, like any building, once a layer or floor is built, it is usually easier to build another layer right on top (of course only if it makes sense to do so).

4.2 - The Individual Layers

A lot of thought has been given to the question "why are three layers necessary to describe the GC SOA?"  The answer is multi-faceted in that:

• Each layer provides the necessary services for the layer above it
• Each layer is self-describing, and
• Each layer embodies a particular architectural or technological concept

The three layers defined within the GC SOA are:

Layer 1 - Technology Component Architecture

Layer 2 - Service Exchange Architecture

Layer 3 - Business Application Architecture

Each layer will now be discussed in turn.

4.2.1 - Technology Component Architecture - Layer 1

Figure 4 - Technology Component Architecture (TCA) - GC SOA Layer 1

The Technology Component Architecture (TCA) contains vendor specific products, services and their supporting architectures and identifies the lowest level components that can be re-used across the GC "out-of-the-box".  In other words, you can reuse it as-is. There is no formal way to use just part of it, or alter its intended behaviour. In essence, it is a black box that does what it does. This layer contains all of the hardware and software required to expose the building block components (regardless of complexity and size) offered by the vendors.  Examples of these components might be the Java language or computer video card. They are what they are; you use them as they exist and have little opportunity to alter their capabilities without involving their vendor/supplier. Each of the products are assumed to be self contained and non-interacting. The expectation of interoperability in this layer is not warranted as each vendor has the right to use standards appropriate for their own implementation. This does not mean however, vendors could not and should not try to interoperate with each other directly, and in fact some actually succeed in doing so, it simply is not a requirement that the Government of Canada places on vendors.

An important consideration in this layer is the degree of granularity. In other words, how bite-sized are the components that have been made available by the vendor/builder. More granularity implies more flexibility in customizing a system, because there are more, smaller increments (granules) from which to choose.

Legacy applications that standalone and are built directly on vendor platforms can also be considered a part of the TCA. These in-house applications are treated exactly the same way as vendor products due to the fact that the only significant differentiating factor is who developed it.  Of course, infrastructure products offered by vendors typically are more easily brought into the service-oriented model, but with today's adapter technologies and available efficient custom coding techniques, applications also can be considered technology and process service providers.

4.2.2 - Service Exchange Architecture - Layer 2

Figure 5 - Service Exchange Architecture (SEA)  - GC SOA Layer 2

The Service Exchange Architecture (SEA) is the middle layer that supports the one-to-one mapping of a component offering in the TCA layer to what is termed an infrastructure service or i-service. For example, task management and calendaring are components of e-mail, which can be represented, treated and utilized separately. Usually what transpires is that a standardized service template is made available to wrap the vender specific service in order to conform to any GC wide standard. These infrastructure services would then be used as building blocks upon which other value-add theme-based services (e.g. travel or health services) could be built and exposed.

Automated Business Services, also called composite services in the IT industry, are services composed of other services and they represent the key value-add proposition of the SEA. Typically composite services deliver key business functions or processes that are part of some higher order application or program delivery vehicle. The higher order composite service consumer may be other internal services, applications or external services for citizens or business. 

Regardless of usage, the recursive nature of services calling services allows for program complexity where warranted or simplicity when desired. Figure 5 has been simplified and simply shows a single composite layer referred to as the Automated Business Services although a composite service can consist of other composite services to any depth.

Of special significance to this layer is the distinction between services exposed using proprietary or industry standard interfaces vs. services which are exposed using GC wide approved interfaces. Examples of industry interfaces include ebXML, Web Services and traditional EAI (Enterprise Application Integration). An example GC wide approved interface might be the XML based interface to the Secure Channel services broker. In instances when there is no need to tailor an industry standard, the GC approved standard might be identical to the industry standard. One such example is the GC adopting POP3 as the interface between any e-mail client program and the many GC mail servers.

Figure 6 - TCA to SEA common service exposure, shows vendors exposing an interface within the TCA as a component. Although many vendors are moving to less proprietary interfaces which is very positive, to be considered an i-service in the SEA layer, TCA component functionality must be offered via a GC wide approved interface. 

In the SEA layer, the GC SOA can simply adopt industry interfaces that are sufficiently broad such that all departments can be assured of interoperability by selecting such services from fully compliant vendors and sources. In other instances the GC SOA will promote "wrapping" thecomponents and their interfaces with a GC wide standard defined centrally. This will insulate departments from the actual service providers at the TCA layer and provide a strong degree of vendor independence.

When such wrapping does occur, potentially the message header (as part of the service call on the wire) will be considered along with the message contents (also called the payload). In some cases the wrapping will simply provide insulation in the header portion. In other instances, the payload will also be manipulated by the wrapping interface.

Figure 6 -TCA to SEA common service exposure

4.2.3 - Business Application Architecture - Layer 3

Figure 7 - Business Application Architecture (BAA) - GC SOA Layer 3

The Business Application Architecture (BAA) is at the top of the architecture stack.  In essence, it allows business owners to package a selection of GC (or non-GC) services to be used in a new value proposition for the crown.  Typically the scope of an application is flexible and it can be defined to include a little more or a little less functionality depending on the time and resources available. Applications can be created through new code, acquired code, or repurposing existing code.  For example, by repurposing existing departmental and cross-jurisdictional health related services, one could create a composite real-time and location independent health and travel advisory service, including food recalls, air quality, and medical clinic information for use in a single window for travellers.  Such contemporary public services would leverage new and existing public and/or private services depending upon the service levels and access controls associated with them.

By their very nature, applications within the BAA layer are incapable of "direct" reuse. The users of the applications are generally people suggesting the BAA contains those elements of the architecture related to service delivery.  To support inter-operability between applications in this layer, the applications must utilize services located in the Service Exchange Architecture layer where information exchange is made possible.  In other words the BAA layer is the presentation layer along with any associated interaction logic and other non-reusable aspects of a business application.

The BAA is also decomposed into its own distinct layers. These layers are connected via an Application Services Bus (ASB), which can be proprietary and/or local to the application. When interactions to the SEA layer are involved then an Enterprise Services Interface (ESI) provides a standardised model for external service consumption.

To ensure the lower level components are as reusable as possible the BAA maintains in its internal Process layer and Persistence layer the business specific rules and data that are distinctive to this business instance.  When a process layer function is common across many BAA instances then it too, becomes a candidate to move down the GC SOA stack to the SEA layer and gets exposed as a new service.   

Figure 8 - BAA internal layers and communication mechanisms

The following is a brief overview of the layers internal to the BAA.

Presentation Layer  - Displays content, prompts and results on whatever device is being used
(e.g. browser, cell phone, PDA, 3270 screen etc) including transformation functions to support accessibility technologies

Interaction Layer - - Deals with end user guidance and management of data capture, processes and inter-service interoperability (back button, help, change menu, etc)

Process Layer  - Manages the overall logic and workflow for the session. Includes models of business processes that enable service consumers and service providers to have a shared understanding of each process and to select processes and services based on responses from the service partner

Object Layer  - - Handles any BAA specific business rules such as data validation. Includes items that are modeled in accordance with a COI adopted object model standards (e.g. business information entities defined according to the UN\CEFACT specifications and guidelines for core components - an application of ISO 11179).

Persistence Layer  - Handles information retrieval and storage needed to maintain session continuity including technologies such as digital signatures and encryptions that safeguard the integrity of objects interchanged between service exchange participants and the guidance on storing them.

The BAA contains a range of applications, from the tightly focused single purpose application to the large multi-purpose behemoth. The BAA also contains applications that are truly unique or "one-of" to a particular business unit or program or even a department. In the past, without a strong service orientation and well-defined standards, the tendency was to build larger and larger applications that covered a wide breadth of business needs. This helped ensure that all the various pieces of the solutions could interact and function as a whole.

The GC SOA will have the tendency to foster the growth of smaller more focused applications, once people break out of the mind set that the project (or program) and the application are different. For instance, in the above figure, we may have a health and travel advisory project with the key deliverable from this project being sometimes thought of as the health and travel advisory application. In a service-oriented world, the "application" will be more synonymous with a portfolio or collection of components related to health and travel brought together for the expressed business purpose of providing a comprehensive advisory service. If and when the business services are reused (or changed) then the top-level application(s) can also be refocused.

A significant amount of the BAA architecture focuses on the design-time aspects of application design since the models and patterns applicable to it can be shared and re-used amongst a number of applications during the development phase. It is these models and patterns that will be the focus of discussion in the detailed documents to come.

4.3 - Another Perspective on the 3 Layers

The GC SOA can be viewed from another perspective for those still perplexed as to how the layers fit together.

Figure 9 - GC SOA alternate perspective

Although Figure 9 shows a simplistic segmented view of design-time and run-time partitioning, by no means is it true that all of the design is done at the top layer. The design of services is still done in layer 2, but the main focus or output of layer 2 is an interoperable run-time environment.

• Previous Page
• Table of Contents
• Next Page