In an earlier blog I highlighted some of the concepts around service orientation. In this blog I want to cover some aspects of a SOA reference architecture. The concepts of Service-Oriented Architecture have been around for some time now; however, there was little focus on standards. Standards-based infrastructure technology enables SOA and make it realistic to achieve.
The pathway to SOA Infrastructure that has emerged as a logical evolution built on past infrastructure and largely based on standards.
Some of the major challenges that arise with SOA without the assistance of a SOA infrastructure include:
- Avoiding tightly coupled Service connectivity which results in a rigid and inflexible architecture.
- Achieving a consistent data format and representation of enterprise data entities.
- Understanding which Services are available, where they reside, their contract, invocation protocols, and rules for use.
- Monitoring and enforcing quality of service such as service level agreements described by Service contracts.
- Managing Service versioning and Service life cycle requirements.
- Establishing the centralized management of security policies for SOA participants.
- Achieving flexibility where coarse grained Services and applications can be composed of existing Services.
- Invoking Services over heterogeneous transports using varying message brokering capabilities.
- Achieving the performance and SLA requirements in a highly distributed and heterogeneous environment.
Logical Architecture
Before deciding which commercial or open source software to utilize as part of your SOA infrastructure, I like to look at the required architecture capabilities and define an overall logical architecture first.
Service Consumers
Service consumers are, of course, consumers of Services, but more importantly, they do not offer any SOA capabilities nor are they required to conform to SOA principles (assuming they are not also Service providers)
A special mention should be given to Composite Applications. I use this term to refer to applications that are built primarily of Services. As the portfolio of Services increases, the ability to rapidly compose new applications increases. The ratio of Services that already exist versus Services that need to be built changes over time. Eventually, composite applications may be composed almost entirely of existing Services.
The BPM Process contained in Composite Applications refers to any type of process that is a Service consumer, but not a Service provider; other processes exposed as Services would all be classified in the Business Process Service layer. In an earlier blog I went into more detail regarding the BPM and SOA relationship.
Service Layers
In order for Services to be versatile and support reuse, there must be a clear separation of concerns in terms of what they do from how they are used.
Services should be written to accomplish their function regardless of what protocol is used to invoke them, where they physically exist, or on what type of hardware or operating system they run. This provides for maximum reuse by allowing access through multiple types of interfaces. It also provides greater versatility in how they are deployed and what underlying technologies are used.
The logical architecture defines 6 logical categories of Services – Presentation, Business Process, Business Activity, Data, Connectivity and Utility Services.
- Utility Services – are not directly related to performing business operations. That is, any Service that is not providing the connectivity, data management, business, or presentation logic associated with a business activity. Utility Services generally perform infrastructure-related functions, such as security (credential mapping, access control, auditing), logging, notification, policy lookup, transaction watermarking, etc.
- Connectivity Services – provide a means to bridge current application technologies with SOA. They establish connectivity with legacy applications that do not inherently provide service-oriented interfaces. Connectivity may be accomplished using a variety of means, such as messaging systems, application adapters, and custom code.
- Data Services – are used to access data from various sources using many different technologies, and present data in a business-friendly form. Data may originate in various databases, flat files, XML/JSON files, and legacy systems. Data Services offer a way to aggregate, transform, and synchronize data from multiple sources. They expose data in a format that best supports business Services and composite business applications. This creates an abstraction between the users of data and the sources of data. Users of data do not need to be concerned with where data is stored, how it is stored, or how it is represented in its native form.
- Business Services – Represent operations that either have a high likelihood of reuse OR a significant value to the organization. Business services come in 2 flavors. Business Activity Services and Business Process Services. The sometimes subtle reason for the separation of the two types of Business Services is that, while Business Activity Services focus on static business functions, Business Process Services provide dynamic workflow orchestrations of business functions.
- Presentation Services – Since all Service layers discussed so far are presentation-neutral, the consumer of those Services must perform presentation-specific formatting before the information reaches the client. There are occasions where reuse can be beneficial after presentation formatting and/or information aggregation is performed. The most common example is a portal. The portal application is divided into portlets which contain information from various sources and the ability to interact with underlying systems
Service Providers
Service providers come in many forms including legacy systems, packaged applications, partner applications, messaging systems, custom-built standalone Services, business processes, and combinations of these. Service enabled applications that are service providers are essentially applications deployed with embedded Services; they can be sub-categorized into various types such as Packaged Applications, Partner Applications (which includes SaaS, cloud, etc.), and Custom Applications.
It is important to note that providing a Service is more than simply providing an interface to invoke a business function. The Service provider must ensure that qualities of Service are stated, offered, and adhered to. This is especially important for Services of an enterprise-class nature, i.e., Services advertised for use across departmental boundaries and/or Services that are leveraged by mission-critical solutions.
Not all packaged, partner, or custom applications are service enabled. These
non-service enabled assets (also referred to as legacy or traditional applications) do not consume or provide services: instead their functionality (or data) is merely wrapped (or encapsulated) and used by other Services either via the connectivity Service layer or embedded directly within a Service of another layer.
An Enterprise Architect's Musings 