Download Reference Architecture

NOT PROTECTIVELY MARKED
Enterprise Architecture 2009
Reference Architecture
Enterprise Service Bus
June 2010
Version:
1.0
Editor Mike Williams
Status: Issued
Date: 16 June 2010
HA Reference Architecture
________________________________________________________________________
Document Control
Reference Architecture – Enterprise Service Bus (ESB)
Mike Williams
Ivan Wells
General – SHARE and PartnerNET
Issued
Document Title
Author
Owner
Distribution
Document Status
Revision History
Version
0.1
1.0
Date
20th October 2009
16th June 2010
Description
First draft.
Baseline issue.
Author
Mike Williams
Mike Williams
Forecast Changes
Version
Date
Description
Reviewer List
Name
Role
Ivan Wells
Reviewer
Various
External peer review
Approvals
Name
Title
Ivan Wells
Strategy and Architecture
Date
Version
Document References
Document Title
Document Links
_________________________________________________________________________
11/05/2017 v1.0
Page 2 of 13
HA Reference Architecture
________________________________________________________________________
CONTENTS
1
INTRODUCTION ........................................................................................................... 4
1.1
PREAMBLE ................................................................................................................... 4
1.2
RELATIONSHIP TO TECHNICAL REFERENCE MODEL (TRM) ............................................. 4
2
PLATFORM INDEPENDENT MODEL (PIM) ................................................................. 6
2.1
SUMMARY DESCRIPTION AND OVERVIEW ....................................................................... 6
2.2
JAVA BUSINESS INTEGRATION ....................................................................................... 6
2.3
WEB SERVICES INVOCATION FRAMEWORK ..................................................................... 7
2.4
JAVA CONNECTOR ARCHITECTURE (JCA) ...................................................................... 7
2.5
JAVA MANAGEMENT EXTENSIONS (JMX) ....................................................................... 9
3
PLATFORM SPECIFIC MODEL .................................................................................. 11
3.1
OVERVIEW ................................................................................................................. 11
3.2
FUSE ESB................................................................................................................ 11
3.3
FUSE MESSAGE BROKER .......................................................................................... 12
3.4
FUSE SERVICES FRAMEWORK ................................................................................... 12
3.5
FUSE MEDIATION ROUTER ......................................................................................... 13
3.6
FUSE INTEGRATION DESIGNER .................................................................................. 13
3.7
FUSE HQ ................................................................................................................. 13
_________________________________________________________________________
11/05/2017 v1.0
Page 3 of 13
HA Reference Architecture
________________________________________________________________________
1
INTRODUCTION
1.1 Preamble
Reference architectures describe one or more Architecture Building Blocks for architectures
in a particular domain. They also provide a common vocabulary with which to discuss
implementations, often with the aim of stressing commonality. In Model-Driven Architecture
(MDA) terms, they equate to Platform Independent Models (PIM’s).
These represent (potentially re-usable) components of business, ICT, or architectural capability
that can be combined with other building blocks to deliver architectures and solutions. Building
blocks can be defined at various levels of detail, depending on which stage of architecture
development has been reached. For instance, at an early stage, a building block can simply
consist of a name, or an outline description, in architecture models which represent a
placeholder for subsequent specifications. Later on, a building block may be decomposed into
multiple supporting building blocks that may then be accompanied by full specifications.
Reference Implementations are examples of software specifications. These are intended as a
guide for Service Providers to develop concrete Solution Building Blocks (SBB’s). In ModelDriven Architecture (MDA) terms, they equate to Platform Specific Models (PSM’s).
These PSM’s are described as either Commercial-Off-The-Shelf (COTS) or Open Source
Software (OSS). In this respect, the HA Technology Policies are aligned with CrossGovernment Enterprise Architecture (xGEA) Technical Policies. These specify that OSS
components should be considered as viable building blocks wherever they can be shown to
meet the business requirements and offer Value for Money (VfM). Therefore, actual product
selections will generally be determined through procurements and their evaluations of the Most
Economically Advantageous Tenders (MEAT).
Where such selections have already been made, the Reference Implementations will be
superseded by Level 2 (Physical) Technology Policies which reinforce the use of those
components. Some of these components will stem from a build out, through re-use, of the HA’s
more recently acquired, existing infrastructure assets and investments, such as in Business
Intelligence. In all other cases, the PSM’s will be based on OSS projects which implement the
relevant Open Standards.
1.2 Relationship to Technical Reference Model (TRM)
This reference architecture refers to the Enterprise Service Bus (ESB) which is a sub-set of the
SOA Service Fabric.
_________________________________________________________________________
11/05/2017 v1.0
Page 4 of 13
HA Reference Architecture
________________________________________________________________________
Figure 1 - TRM Context
_________________________________________________________________________
11/05/2017 v1.0
Page 5 of 13
HA Reference Architecture
________________________________________________________________________
2 PLATFORM INDEPENDENT MODEL (PIM)
2.1 Summary Description and Overview
The reference architecture for the ESB is comprised of the following Open Systems, Javabased specifications:

Java Business Integration (JBI): A specification developed under the Java Community
Process (JCP) that describes the way that integration components can be plugged
together in a vendor-neutral and portable manner.

Web Services Invocation Framework (WSIF): An open-ended framework for invoking
Web Services Description Language (WSDL) described services.

J2EE Connector Architecture (JCA): A specification that defines the use of a standard
set of interface contracts to inter-connect enterprise applications.

Java Management eXtensions (JMX): A specification for remote management of
applications and services through standard management consoles which includes:
o
Configuration data,
o
Commands for controlling service lifecycles,
o
Runtime alerts and event notifications,
o
Health monitoring, and
o
Statistics gathering.
2.2 Java Business Integration
JBI is a Java-based standard (JSR208) to build integrations by using plug-in components which
interoperate through mediated normalised message exchanges. The message exchange model
is based on the Web Services Description Language (WSDL).
Figure 2 below illustrates the high-level conceptual model for JBI’s plug-in framework which
facilitates the loose-coupling required for a Service Oriented Architecture (SOA). The JBI
environment provides interfaces to be used by a number of plug-in components. The
component plug-ins do not interact with each other directly. Instead, the JBI environment acts
as an intermediary to route messages between components. This separation is the key to
loose-coupling between service providers and consumers, which is one of the primary goals of
SOA’s. In addition, it provides a key point for message processing and monitoring.
Figure 2 - JBI Plug-in Model
_________________________________________________________________________
11/05/2017 v1.0
Page 6 of 13
HA Reference Architecture
________________________________________________________________________
2.3 Web Services Invocation Framework
Information systems often consist of many different software components, such as legacy
applications which were developed on different platforms. To integrate all these components,
integrators have to deal with numerous, disparate protocols. For example, if software migrates
to a different server or has been upgraded to use a new technology, then any integrations need
to be re-engineered. However, it has become more common practice to expose all of these
applications and their legacy API’s as SOAP-based Web Services.
The Web Services Invocation Framework (WSIF) enables many of these legacy services to be
invoked by service consumers as if they were Web Services without them actually having been
implemented as such. By defining, in an extended WSDL document, what the service looks like
in functional terms and how it can be invoked in terms of protocol and physical location, the
WSIF framework can translate a simple service call from the service consumer into the required
native protocol call. It also transforms the service response back into a generic response
format. As a result, the service consumer needs no knowledge of the actual implementation of
the service - that is all abstracted by WSIF and its protocol-specific providers. This is illustrated
in Figure 3 below.
Figure 3 - The Web Services Invocation Framework
2.4 Java Connector Architecture (JCA)
Prior to the advent of the J2EE Connector Architecture, integrating a J2EE application and an
Enterprise Information System (EIS) was complex and problematic, as there were no existing
standards for such integrations. Each EIS vendor supplied their own proprietary solution to the
problem and usually didn't support all J2EE application server platforms. This made it very
difficult to develop truly portable applications that integrated with enterprise information systems
- a custom effort was needed to integrate each application server and EIS combination.
Figure 4 below illustrates the J2EE application and EIS integration complexity.
_________________________________________________________________________
11/05/2017 v1.0
Page 7 of 13
HA Reference Architecture
________________________________________________________________________
Figure 4 - Integration before and after JCA
JCA is composed of three primary elements:
2.4.1

System contracts.

Client API.

Resource adapter module.
System contracts
System contracts define the interfaces between the application servers and the EIS’s. The EIS
side of the system contract is implemented by a resource adapter – a system-level software
driver specific to a particular EIS. The application server and the resource adapter collaborate
by means of the system contract to provide secure, robust, scalable access to the EIS.
Three types of system contracts are defined:
•
•
•
The connection management contract enables physical connections to the EIS and
provides a mechanism for the application server to pool those connections.
The transaction management contract supports access to an EIS in a transactional
context. Transactions can be managed by the application server, providing
transactions that incorporate other resources besides the EIS, or they can be internal
to the EIS resource manager, in which case no transaction manager is required.
The security contract supports secure access to the EIS.
How system contracts are implemented on each side (application server and resource adapter)
is not specified by JCA; they can be implemented as each vendor sees fit.
2.4.2
Client API
The second element of JCA is the client API. The API can be specific to the resource adapter
or it can be the standard Common Client Interface (CCI) as defined by JCA. The CCI is
intended to be used by vendors to provide integration tools and frameworks, making it easier
for developers to access enterprise systems. It is recommended (but not mandated) that the
resource adapter make use of the CCI.
_________________________________________________________________________
11/05/2017 v1.0
Page 8 of 13
HA Reference Architecture
________________________________________________________________________
2.4.3
Resource adapter module
The resource adapter module contains all of the elements necessary to provide EIS
connectivity to applications. Specifically, the resource adapter module includes the following
components:
•
•
•
•
The Java classes and interfaces that implement the resource adapter.
Any utility Java classes required by the resource adapter.
Any EIS-specific platform-dependent, native libraries.
The deployment descriptor.
Application servers make use of the deployment descriptor supplied with a resource adapter to
configure it to a specific operational environment.
2.5
Java Management eXtensions (JMX)
The Java Management Extensions (JMX) API is a standard, developed through the Java
Community Process (JCP) as JSR 3, for managing and monitoring applications and services. It
defines a management architecture, design patterns, API’s, and services for building webbased, distributed, dynamic, and modular solutions to manage Java-enabled resources. The
JMX API’s make it possible to add manageability to Java-enabled equipment, from web phones
to set-top boxes to network devices and servers. Using JMX technology to manage services
increases their added-value by making applications easier to install, configure, and maintain.
JMX technology provides a tiered architecture where managed resources and management
applications can be integrated in the plug-and-play approach as shown in Figure 5. A given
resource is instrumented at the Probe Level by one or more Java objects known as Managed
Beans (or MBeans), which are registered in a core managed object server known as the
MBean server. This server acts as a management agent and can run on most Java-enabled
devices.
Figure 5 - JMX Architecture
_________________________________________________________________________
11/05/2017 v1.0
Page 9 of 13
HA Reference Architecture
________________________________________________________________________
There are three tiers or levels in this architecture:
• Instrumentation (or Probe);
• Agent; and
• Remote Management.
2.5.1
Instrumentation (Probe) Level
This level contains MBeans and their manageable resources. It provides a specification for
implementing JMX technology-manageable resources, which can be an application, service,
device, or user. A resource is manageable if it is developed in Java (or provides a Java
wrapper) and has been instrumented so that it can be managed by JMX-compliant applications.
A resource is instrumented by one or more MBeans that are either standard or dynamic.
Standard MBeans are Java objects that conform to certain design patterns (for example, they
must have a constructor and setter/getter methods). A dynamic MBean conforms to a specific
interface that offers more flexibility at runtime. The instrumentation of a resource allows it to be
manageable at the agent level; however, MBeans do not require knowledge of the JMX agent
with which they operate. In other words, any JMX-manageable resource can use any JMX
agent that offers the services it requires.
2.5.2
Agent Level
This level contains the JMX agents used to expose the MBeans. It provides a specification for
implementing agents, which control the resources and make them available to remote
management applications. Agents are usually located on the same device as the resources
they manage, but this is not a necessary pre-requisite. The JMX agent consists of an MBean
server and a set of services for handling MBeans. Managers access an agent's MBeans and
use the provided services through a protocol adaptor or connector. However, JMX agents do
not require any knowledge of the remote management applications that use them.
2.5.3
Remote Management Level
This level contains the components that enable management applications to communicate with
JMX agents. It provides the interfaces for implementing JMX managers, and defines the
management interfaces and components that operate on agents. Such components provide an
interface for a management application to interact with an agent and its JMX manageable
resources through a connector, and also expose a management view of a JMX agent and its
MBeans by mapping their semantic meaning into the constructs of a data-rich protocol (such as
XML).
_________________________________________________________________________
11/05/2017 v1.0
Page 10 of 13
HA Reference Architecture
________________________________________________________________________
3 PLATFORM SPECIFIC MODEL
3.1 Overview
The chosen reference implementation for the ESB is FUSE. This is based on the fact that the
HA is a “greenfield site” for ESB’s coupled with the fact that it’s Open Source Software (OSS),
which is in line with Government policy.
FUSE, is a distribution of open source SOA tools (much like “Red Hat” is a distribution of the
Linux operating system). It’s a set of standards-based enterprise integration products based on
popular Apache SOA projects. The FUSE Team includes the 4 Project Management Committee
(PMC) chairs, 4 Apache Members, and over 20 active Apache committers on the projects. The
FUSE Architecture is shown in Figure 6 below.
Figure 6 - FUSE Architecture
The main components are described in outline in the following sections.
3.2 FUSE ESB
FUSE ESB a fully standards-based and open source integration platform based on Apache
ServiceMix. It is a robust application integration infrastructure that supports flexible deployment
configurations ranging from embedded, Java J2EE, and standalone OSGi containers.
FUSE ESB has a pluggable architecture that allows organisations to implement their preferred
service solutions in a standards-based SOA. Any standard JBI service engine or binding
component or OSGi-compliant bundle, including BPEL, XSLT or JMX engines, may be
_________________________________________________________________________
11/05/2017 v1.0
Page 11 of 13
HA Reference Architecture
________________________________________________________________________
deployed to a FUSE ESB container, and FUSE ESB components may be deployed to other
ESB’s.
SUPPORTED STANDARDS: FUSE ESB strictly adheres to industry standards beyond OSGi
and JBI, and supports JMS 1.1; AJAX, REST, HTTP, TCP, SSL, UDP and multicast transport
protocols; Web services standards SOAP, WSDL, JAX-WS, JAX-RS, WS-Security and WSReliableMessaging; dependent specifications such as JTA and JNDI; email and FTP; Through
its internal JBI-based API’s, FUSE ESB supports WS-BPEL 2.0 for orchestration, XSLT,
XQuery, Smooks frameworks, and JMX-compliant solutions for systems management.
Further details can be found at: http://fusesource.com/products/enterprise-servicemix4/.
3.3 FUSE Message Broker
FUSE Message Broker is an open source JMS message broker that is based on Apache
ActiveMQ. It is a JMS platform for scalable, high-performance infrastructure to connect
processes across heterogeneous systems.
Figure 7 ActiveMQ Architecture
Further details can be found at: http://fusesource.com/products/enterprise-activemq/.
3.4 FUSE Services Framework
FUSE Services Framework is a flexible open source SOAP and REST web services platform
based on Apache CXF. It is lightweight and easily service-enables existing systems to leverage
new and legacy applications in an enterprise infrastructure.
_________________________________________________________________________
11/05/2017 v1.0
Page 12 of 13
HA Reference Architecture
________________________________________________________________________
Figure 8 - FUSE Services Framework Architecture
Further details can be found at: http://fusesource.com/products/enterprise-cxf/.
3.5 FUSE Mediation Router
FUSE Mediation Router is an open source tool for integrating services, applications, and
transport protocols using Enterprise Integration Patterns based on Apache Camel. It uses a
standard method of notation to go from diagram to implementation without coding.
Further details can be found at: http://fusesource.com/products/enterprise-camel/.
3.6 FUSE Integration Designer
FUSE Integration Designer is an Eclipse-based tool for creating and integrating Web services
using Enterprise Integration Patterns (EIP’s) as a standard method of notation for integration 1.
The Designer includes a canvas for visualising, creating and debugging EIP’s and wizards for
generating and deploying services.
Further details can be found at: http://fusesource.com/products/fuse-integration-designer/.
3.7 FUSE HQ
FUSE HQ is a management and monitoring system available as a part of a FUSE support
subscription. It is integrated with the FUSE product family for real-time administration and
control of FUSE-based infrastructures.
Further details can be found at: http://fusesource.com/products/fuse-hq/.
1
See http://www.eaipatterns.com/.
_________________________________________________________________________
11/05/2017 v1.0
Page 13 of 13