IBM SOA Reference Architecture
IBM's SOA Reference Architecture defines a vendor and technology agnostic set of comprehensive IT capabilities that are required to support your SOA at each stage in a typical SOA life cycle. When an organization defines a solution architecture based on this reference architecture, they would not need all of the capabilities needed initially. But over time, to be successful in SOA, all the capabilities need to be evolved and added.
What is Reference Architecture?
A Reference Architecture captures the essence of the architecture of a collection of systems. It models the abstract architectural elements in the domain or a solution area, independent of the technologies, products, and protocols that are used to implement the domain. It differs from a reference model in that a reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain. Thus reference architecture is useful for:
Providing a common ground domain model
Basis for realizing an architecture vision
Providing key architectural guidance and a blueprint as a baseline
Reference architecture is typically abstract and is abstract for a purpose. You typically instantiate or create solution/system architectures based on the reference architecture. Example reference architecture includes Unisys 3D Blueprints, IBM Insurance Application Architecture, and NGOSS reference architecture from the TM Forum, and so on.
Key elements of IBM SOA Reference Architecture
The IBM Software Reference Architecture is a reference model that lets you leverage information, applications, and tools as services in an interoperable, system-independent way. The subsequent diagram shows the IBM SOA Reference Architecture organized around the key capabilities required for building any SOA-based solution.
Development Services provide the capabilities in terms of development tools for the end users to efficiently complete specific tasks and create specific output based on their skills.
Interaction Services provide the user interaction capabilities required to deliver the Business Services and data to end users.
Process Services provide the control, management, choreography, and orchestration of the business processes that interact with multiple services.
Information Services provide the capabilities required to federate, unionize, and transform data from one or multiple applications or data sources and expose them as services.
Enterprise Service Bus delivers all the connectivity capabilities required to leverage and use services implemented across the entire organization.
Business Innovation and Optimization Services provide the monitoring capabilities and manage the runtime implementations at both the IT and business process levels.
Business Application Services are services provided by existing applications or ones that will have to be exposed by the applications itself including third-party systems.
Access Services allow access to the end applications, legacy applications, pre-packaged applications, enterprise data stores (including relational, hierarchical, and nontraditional, unstructured sources such as XML and Text), and so on using a consistent approach. These typically leverage the business application services.
Infrastructure Services provide security, directory, IT system management, and virtualization capabilities to the SOA solution.
Partner Services provide the capabilities for the efficient implementation of business-to-business processes and interactions.
So what is the relationship between the process integration, key capabilities needed for successful process integration, SOA, IBM SOA reference architecture, IBM WebSphere Process Server, and IBM WebSphere Enterprise Service Bus? The answer is pretty obvious. The book is about how you build SOA solutions with these two products and these two products indeed provide a majority of the capabilities, if not all, which are essential to a successful SOA. Now let's delve into what these two products are all about.
Having defined the essential elements for a BPM enabled by SOA approach, having explained the need for a reference architecture, and in particular, what IBM's SOA reference architecture is all about how does it all come together? How would a (reference) solution architecture, based on the IBM SOA Reference Architecture, look? The following figure shows one such instantiation of the "BPM enabled by SOA" solution architecture. It incorporates all of the building explained above, as categorized and organized into the appropriate IBM SOA reference architecture buckets/layers. Also, what each layer and each building block should have as capabilities within itself is explained.
