Building blocks and services – more detailed analysis

TOGAF® and ArchiMate® are registered trademarks of The Open Group.

This second paper is a supplement to a paper you probably ought to read first.

That first paper maps TOGAF to ArchiMate and looks at TOGAF more widely.

This second paper adds more detail to the first paper above, by way TOGAF building block concepts and examples.

Contents

TOGAF’s generic concepts and principles (REPEAT) 1

Services in the different domains. 3

The structural view of a system.. 4

A few illustrations. 7

Building blocks in TOGAF’s Architecture Development Method. 8

Building blocks in TOGAF’s Content Framework. 9

Logical and physical building blocks. 12

Notes on the use of ArchiMate symbols. 14

Footnote: more illustrations. 15

TOGAF’s logical concepts and principles (REPEAT)

“The Open Group is a global consortium that enables the achievement of business objectives through technology standards.”

TOGAF is management framework for designing, planning and governing changes to business systems – under change control.

Before putting technologies to use, TOGAF encourages logical technology-independent specification of business systems.

Understanding TOGAF’s logical architecture definition principles helps to people to read it in a coherent and consistent way.

TOGAF says of enterprise architecture:

“EA regards the enterprise as a system, or systems of systems”

“Systems are built up from … building blocks [that] interoperate with other building blocks.”

“The major work… consists of identifying the architecture building blocks required to meet the business goals and objectives.”

“An architecture is a set of building blocks depicted in an architectural model.”

“A building block’s boundary and specification should be loosely coupled to its implementation."

“For each building block, build up a service description portfolio as a set of non-conflicting services.”

"A service is a logical representation of a repeatable business activity that has a specified outcome”

“It is important that the interfaces to a building block are published and reasonably stable.” TOGAF 9.1

The Open Group’s (executable standard) principle is to abstract from the internal behaviors of structural components by defining the services they offer.

The approach to architecture definition in TOGAF may be distilled as:

· The Architecture Requirement Specification includes contracts for services offered by business and IS/application building blocks.

· Architecture building blocks (ABBs) are logical components defined by the services or flows they provide to each other and to external entities.

· Solution building blocks (SBBs) are physical components hired, bought or built to realise ABBs, and so deliver the required services or flows.

· SBBs are defined by the ABBs they realise, along with vendor-specific and implementation-specific details.

The implicit generic meta model is: required services <are assigned to> logical ABBs <are realised by> physical SBBs.

The generic meta model is specialised in three architecture domain/layers thus.

	Required behaviors	aassigned to logical structures	realised by physical structures
	Services	ABBs	SBBs
Business	Business Services	Functions	Organisation Units
Business	Business Services	Roles	Actors
IS/Applications	IS/Application Services	Logical Application Components	Physical Application Components
Technology	Platform Services	Logical Technology Components	Physical Technology Components

Which can alternatively be tabulated thus.

ArchiMate-compatible generic concept definitions	Business	IS/Applications	Technology
Required behavior element Service: a requestable behaviour that has entry conditions (preconditions, trigger, inputs) and exit conditions or outcomes (outputs and post-conditions). Process: a flow of activities that runs from a start to an end result.	Business Service Process	IS/Application Service	Platform/Technology Service
Logical structure element An abstract specification of what one or more physical actors can do	Function Role	Logical Application Component	Logical Technology Component
Physical structure element An encapsulation of behaviors and other resources. It realises services by performing activities in processes.	Organisation Unit Actor	Physical Application Component	Physical Technology Component

The TOGAF standard (reflecting The Open Group’s principle) has always been thoroughly service-oriented.

A service is a logical representation of a repeatable activity that has a specified outcome.

ArchiMate 3.0.1 compared with TOGAF 9.1

TOGAF is about the logical architectural specification of systems at an enterprise portfolio management and/or solution architect level.

TOGAF says its physical components are “considerably abstracted” from implementation, from components that actually perform behaviors.

ArchiMate is normally used at level closer to physical implementation, and so a more natural fit to specification at the solution and/or software architect levels.

The table below maps ArchiMate elements to TOGAF elements.

ArchiMate-compatible generic concept definitions		Business	IS/Applications	Technology
Required behavior element Service: a requestable behaviour that has entry conditions (preconditions, trigger, inputs) and exit conditions or outcomes (outputs and post-conditions). Process: a flow of activities that runs from a start to an end result.	TOGAF	Business service Process	IS/Application service	Platform service
	ArchiMate	Business service Business process	Application service	Technology service
Logical structure element An abstract specification of what one or more physical actors can do	TOGAF	Function Role	Logical application component	Logical technology component
	ArchiMate	Business function Business role	Application function OR interface	Technology function OR interface
Physical structure element An encapsulation of behaviors and other resources. It realises services by performing activities in processes.	TOGAF	Organisation unit AND Actor	Physical application component	Physical technology component
	ArchiMate	Business Actor	Application Component	Node

Read the earlier paper for more detailed comparison of TOGAF and ArchiMate.

Services in the different domains

Services in the business layer

“The TOGAF content framework differentiates between the functions of a business and the services of a business.

Business services are specific functions that have explicit, defined boundaries that are explicitly governed.”

The use of the term functions in the definition of services is confusing – fails to differentiate them.

Business organization units, functions and roles are structural building blocks.

Business services and processes are discrete behaviors that deliver “specified outcomes”.

“Services are distinguished from functions through the explicit definition of a service contract.

A service contract covers the business/functional interface and also the technology/data interface.”

A service may depend on the state of stored business data, and may change that state.

So the functional rules in a service contract may define preconditions and post conditions with reference to business state data.

Services in the applications layer

“The organization’s Application Portfolio is captured as a catalog within the Architecture Repository.

Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities

(e.g., logical application component -> physical application component -> information system service).”

This seems a mistake because the meta model says: physical application component <-> logical application component <-> information system service.

The III-RM is a three-layer service-oriented architecture with discrete service requests passing from client apps to service provider apps.

“Information Consumer Applications deliver content to the user of the system, and provide services to request access to information in the system on the user’s behalf

“Brokering Applications manage the requests from any number of clients to and across any number of service providers.

“Information Provider Applications, which provide responses to client requests and rudimentary access to data managed by a particular server.”

Services the technology layer

The Technical Reference Model is the biggest sources of service examples.

It defines both groups of services (sometimes called service portfolios) and individual or discrete services.

E.g. Electronic Mail services include the capability to send, receive, forward, store, display, retrieve... messages.

Each of those is a discrete event-driven service, which encapsulates a start-to-end process.

Similarly,” Transaction manager services include starting a transaction… committing or rolling back a transaction”

(Committing a transaction is process that probably involves thousands of atomic process steps.)

The structural view of a system

This table shows TOGAF and ArchiMate share much by way of core concepts, and use a variety of terms for them.

	Behavior elements names	Structure element names
External view	Service, Service Contract	Interface, Boundary, Service Portfolio
Internal view	Process, Value Stream, Scenario	Building Block, Component, Function, Organisation Unit, Role, Actor, Node

The structural view of a system features these terms and concepts.

Interface: a collection of services requestable by a client; one way to specify a building block, component or other structural node.

Building block: an active structure, a performer of required activities, which interoperates with other building blocks.

Component: a building block defined by the one or more services it offers to clients.

Function: a logical component that clusters cohesive behaviors by some cohesion criterion other than sequence; a subdivision an organisation’s capability (cf. a capability).

A node connectivity, communication or value network diagram can relate structure elements of any kind by the exchange of flows or services.

Interfaces/boundaries

Encapsulation behind interfaces is general principle of all business system design, not just software design.

In this Harvard Business Review piece <https://hbr.org/2011/12/first-lets-fire-all-the-managers> Gary Hamel talks about Morning Star.

“Every year, the 23 business units negotiate customer-supplier agreements [interface specifications] with one another.

And each employee negotiates a Colleague Letter of Understanding [an interface specification] with associates most affected by his or her work.

“As a colleague, I agree to provide this report to you, or load these containers into a truck, or operate a piece of equipment in a certain fashion.” [i.e. I agree to provide this collection of services]

This [interface specification] covers as many as 30 activity areas and spells out all the relevant performance metrics.”

ArchiMate says an interface is a point of access where services are made available.

TOGAF tends to use the terms “interface”, “boundary” and “service portfolio” interchangeably.

(Aside: TOGAF’s “interface catalog” would be better called an information/data flow catalog.)

It is a principle of The Open Group that clients should invoke services via “open” interfaces.

The rationale of TOGAF 1 to 8 has been obscured in TOGAF 9, but it still says:

“For each building block, build up a service description portfolio as a set of non-conflicting services.

The term building block is sometimes replaced by “component” or some other term.

“A key goal of architecture development is for service modules to be capable of replacement by other modules providing the same service functionality via the same service API.”

Those “service modules” are building blocks that each provide multiple discrete services via an interface.

Building blocks/components

TOGAF divides the architecture of an enterprise into building blocks - of many shapes and sizes.

Building block varieties include functions, organization units, roles, human actors and application/technology components.

Building blocks interoperate by requesting and providing services.

Building blocks and the services they offer are composed and decomposed.

One large building block may offer scores of discrete services.

On the other hand, a coarse-grained enterprise-level service may require scores of interacting building blocks.

“A good choice of building blocks can lead to improvements in legacy system integration, interoperability, and flexibility in the creation of new systems and applications.” TOGAF.

TOGAF guidance features the declaration of component-based design principles quoted in the table below.

Note that the definitions below apply to business functions/capabilities and roles - as well as application and technology components.

A Building Block in TOGAF 9.1 (quoted from chapter 37)	An Internal Active Structure Element in ArchiMate 3.0 (written here to match)
· is generally recognizable as "a thing" by domain experts	is a structure element rather than a behavior element.
· is a package of functionality defined to meet the business needs across an organization.	clusters* cohesive behavior elements required by business users (directly or indirectly)
· has published interfaces to access the functionality. (TOGAF 9 replaced “interfaces” by “boundary”)	exposes behaviors in one or more published interfaces.
· may interoperate with other, inter-dependent, building blocks.	interoperates with others, which implies client-server or sender-receiver dependencies
· considers implementation and usage, and evolves to exploit technology and standards.	may be specified with a particular implementation or standard in view.
· may be assembled from other building blocks.	is recursively composable.
· may be a subassembly of other building blocks.	is recursively decomposable.
· is, ideally re-usable and replaceable, and well specified.	should be re-usable and replaceable, and well specified.
· may have multiple implementations but with different inter-dependent building blocks.	should offer services via interfaces that hide implementation variations.
· is therefore simply a package of functionality defined to meet business needs.	clusters* cohesive services required by business users (directly or indirectly).
Systems are built up from … building blocks [that] interoperate with other building blocks.	is related to others by requesting or delivering services.
It is important that the interfaces to a building block are published and reasonably stable.	is encapsulated behind one or more interfaces that are reasonably stable.
For each building block, build up a service description portfolio as a set of non-conflicting services.	clusters cohesive services that are cohesive and performable by an instance.

* In general system theory (and TOGAF) terms:

Abstract/logical building blocks (functions, roles, and logical components) cluster behavior types that concrete building blocks can be nominated to perform.

Concrete/physical building blocks (organisation units, actors and physical components) are nominated to realise or perform instances of behavior types.

A few illustrations

The table below illustrates these concepts in accord with TOGAF’s terminology.

General concepts	Required Behaviors	Logical Structures	Candidate Physical Structures
Generic concepts		ABB	SBB
TOGAF elements	Service portfolios	Functions/Capabilities, Roles	Organisation Units, Actors
Business example	Hairdressing service portfolio · Wash hair · Perm hair · Cut hair · Manicure	Hairdresser	“Curl up and dye” “Cutters and clippers” “Headmasters” Betty next door
Business example	Marketing service portfolio · Research customer requirements · Design campaign · Promote product or service · Analyse customer responses	Marketing	In-house marketing department Out-sourced marketing department
TOGAF elements	Service portfolios	Logical Components	Physical Components
Application example	Customer relations service portfolio · Gather sales leads from social media · Promote product or service · Capture order details · Close deal · Maintain a customer profile · Forecast sales · Send message to sales or service agent · Display dashboard-style analytics	CRM Application	amoCRM Bitrix24 HubSpot Infusionsoft Oracle Siebel Pipedrive Salesforce.com Teamgate CRM
Infrastructure Technology example	The footnote contains technology-specific examples of service portfolios, logical and physical components

Building blocks in TOGAF’s Architecture Development Method

TOGAF defines systems elements at several levels of abstraction removed from an implemented system.

"building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached."

Architects describe building blocks at several levels of abstraction, depending on what stage of architecture development has been reached.

Phase A: Architecture Vision

Architects gather contextual information (business drivers, principles, goals, visions and plans; system stakeholders and their concerns).

They present, refine and agree this information, getting approval to proceed.

They may name business system components (say Billing, or CRM), with a sketchy description.

"At an early stage, a building block can simply consist of a name or an outline description."

Phases B to D: Architecture Development

Architects proceed to define logical application and technology components, and they services they provide.

“A building block’s boundary and specification should be loosely coupled to its implementation”

The description of logical ABBs tends to be generalised, logical and coarse-grained.

Ideally, architects specify ABBs as interface definitions, decoupled from specific solutions. E.g.

· A Billing function is defined by the 20 business services it provides.

· A CRM application is defined by the 15 critical use cases it offers via its interface, and 50 business data entities it maintains.

· An RDBMS is defined by conformance to standards such as SQL, ODBC.

Phases E and F: Planning

Architects identify physical building blocks to realise logical building blocks.

“It should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.”

They might a select a COTS package, e.g. Salesforce.com, Oracle DBMS.

Or produce a technology-specific description of a system to built.

These SBBs are still abstract descriptions, tending to be coarse-grained, and perhaps still somewhat generalised.

“physical elements in an enterprise architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.”

"Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification."

Architects help managers plan the work to implement the physical building blocks

Phases G and H: Implementation and change governance

Remember phase G is not implementation, it is governance of implementation projects carried out in parallel.

“in parallel with Phase G, there is the execution of an organizational-specific development process, where the actual development happens.”

Not all building blocks have been defined at the start of phase G.

“In phase G, the specific SBBs required [to fill gaps] will be the identified by the solutions architects.”

These SBBs are still coarse-grained – they even may be project-sized.

“These solution architecture building blocks may have a one-to-one or many-to-one relationship with the projects.”

Architects monitor the projects that implement new/changed business systems.

“The solutions architects need to define exactly how [reuse of software components] will be done.

There may be other projects working on these same capabilities [here meaning SBBs] and the solutions architects need to ensure that they can leverage best value from these investments.”

(For me, TOGAF abuses the term “solution architects”, this is really the level of software architects, but I quote the TOGAF terminology above.)

Architects ensure compliance of deployed systems with ABBs, changing them if need be.

Later, under change management, maintainers maintain concrete elements of the implemented systems.

Architects continue to ensure the compliance of deployed/operational systems with ABBs, changing them if need be.

Building blocks in TOGAF’s Content Framework

The generic meta model is specialised in different architecture domains thus.

	Required behaviors	aassigned to logical structures	realised by physical structures
	Services	ABBs	SBBs
Business	Business Services	Functions	Organisation Units
Business	Business Services	Roles	Actors
IS/Applications	IS/Application Services	Logical Application Components	Physical Application Components
Technology	Platform Services	Logical Technology Components	Physical Technology Components

Implicit in TOGAF are the equations: function = logical business component, and organisation unit = physical business component.

The abstract/logical building blocks cluster behavior types that concrete building blocks can be nominated to perform.

The concrete/physical building blocks are nominated to realise or perform instances of those behavior types.

The generic architectural entities discussed above have different generic qualities.

E.g. behaviors run over time, whereas physical components occupy space and do work.

Common attributes of Behaviors e.g. Services, Processes, Value Streams, Scenarios

name
start conditions: trigger events, inputs, preconditions for success
end conditions: outputs, results or values delivered, other post conditions
duration
volume or throughout
performers (building blocks).

“Systems concepts include: system-environment boundary, input, output, process, state….” (Principia Cybernetica)

The inputs and outputs of a behavior can include materials/goods as well information/data flows.

The preconditions and post conditions of services and processes can refer to system state, as may be recorded in databases.

Common attributes of Logical Building Blocks e.g. Roles, Business Functions/Capabilities, Logical Application and Technology Components

· name

· provided interface(s) that group services offered

· required interface(s) that group services needed

· behaviors performed

· physical building blocks that implement the logical building block

· + generalised requirements for some of the more physical attributes below.

Common attributes of Physical Building Blocks e.g. Actors, Organisation units, Physical Application and Technology Components

· name

· deployment place(s) or location(s)

· abilities possessed: power and memory, or skills and knowledge

· physical resources used: materials and/or energy

· cost to employ

· predicted life span or retirement date

· logical building blocks realised.

Building blocks in the enterprise continuum

Building blocks are described in artefacts (e.g. an actor/role matrix or business function decomposition) and in deliverables (most notably, an architecture definition document).

TOGAF proposes architects describe building blocks at several levels of abstraction, depending on what stage of architecture development has been reached.

The content framework proposes these specifications are stored in an enterprise repository that is subdivided into requirements, architecture and solutions repositories.

The four rows of the table below map the phases of TOGAF’s architecture development method to these three levels of abstraction, and to operational systems.

Phase of ADM

Elements

Enterprise Continuum

Enterprise Repository

Notable deliverables

Quotes

Preliminary

Principles, Vision, and Requirements

Context and requirements

Requirements repository

Drivers and goals

Principles catalogue

Stakeholder communications plan

Architecture requirements specification

Architecture vision

"Architecture Principles, Vision, and Requirements artifacts are intended to

capture the surrounding context of formal architecture models,

including general architecture principles, strategic context that forms input for

architecture modeling, and requirements generated from the architecture."

B, C and D

ABBs:

e.g. Sales function, CRM, RDBMS.

Architecture continuum

Architecture repository (landscape)

Architecture definition document

“Building blocks are defined in relation to a set of contextual factors."

“An Architecture Definition is “a collection of artifacts that document an architecture”.

“The Enterprise Architect has the responsibility for architectural design and documentation

at a landscape and technical reference model level.”

E and F

SBBs

e.g. Salesforce.com, Oracle DBMS.

Solution continuum

Solution repository

Architecture road map

Implementation and migration plan

G and H

Concrete elements

in deployed solutions.

Deployed

solutions

Operational systems

“This Architecture repository … provides the capability to link architectural assets to

components of the Detailed Design, Deployment, and Service Management Repositories."

Logical and physical building blocks

“[Cybernetics] depends in no essential way on the laws of physics or on the properties of matter.” (Ross Ashby)

A physical component is a material thing that is hired, bought or built to implement/realise specified interfaces (described as “SBB” in TOGAF).

A logical component is a material-independent component description – often specified in terms of a service portfolio provided (an “ABB” in TOGAF).

The Open Group encourages the specification of business systems in an open, vendor-neutral and portable way.

The ADM is an architecture project management method designed to encourage and facilitate EA-level governance.

To this end, it encourages the open, vendor-neutral and portable specifications of SBBs.

It specifies them as vendor-neutral ABBs, each defined by a required service portfolio (and/or a logical data model).

It encourages the EA team to maintain this "open" specification in architecture definition documents and an architecture repository.

And it applies this service-oriented principle to business architecture as well as technical architecture.

An aim is to increase agility by reducing impact analysis and EA-level architecture change management time.

And to help the enterprise whenever it wants to, or needs to, migrate from baseline solutions to new solutions.

In procurement, the EA team can evaluate new solutions or products against the current or required ABBs.

If the ABBs are little or not at all affected by a change, then the EA team can readily approve the change.

So, TOGAF divides building blocks between logical specifications and identifiable hireable/buyable/buildable SBBs.

Eventually, the SBBs are the implemented as physical instances in the run-time or operational system.

Those physical instances could be called "operational building blocks"; however, TOGAF is not designed to address the grey sections of the table below.

It allows the naming of individual human actors and organisation units, but does not expect an architect to identify software classes, objects or component instances.

Structural element types		Structural element instances
Logical ABBs	Physical SBBs	Physical instances in deployed systems (which occupy space and respond when asked to peform behaviors)
A UML class is a logical specification of the behaviors (operations, methods) one or more physical objects can perform.	E.g. A class coded in Java or C#	An object instantiated or deployed in the software system of interest, along with physical resources it needs, so it can respond to requests.
A component is a logical specification of the behaviors (services, uses cases) one or more physical components can perform.	E.g. A named CRM package or DBMS	A component instance deployed in the software system of interest, along with physical resources it needs, so it can respond to requests.
A role is a logical specification of the behaviors (services, duties) one or more physical human actors can perform.	Named actors	A human actor employed or deployed in the business system of interest, along with the rewards and physical resources it needs, so it can respond to requests
A business function is a logical specification of the behaviors (services, processes) one or more physical organisation units can perform.	Named organisation units	An organisation unit instantiated in the business system of interest, along with the budget and physical resources it needs, so it can respond to requests.

A building block is an encapsulated unit of functionality or behavior.

(Or in the case of a data component, it is an encapsulated persistent data structure.)

ABBs = logical component types = vendor and technology neutral service portfolio specifications.

SBBs = physical component types = vendor or technology-specific specifications of what is hired, bought or built to realise the ABBs.

Note that SBB documentation does not necessarily specify the building blocks in more detail than ABBs.

TOGAF says specification at the SBB or physical component level is still "considerably abstracted" from implementation.

Ideally, one ABB maps to one SBB.

Ideally, the ABB is a well-defined service portfolio, and a SBB can be found to deliver it.

Or the ABB is a service portfolio reverse-engineered from a known SBB.

Or the ABB is a service portfolio already defined in an “open” interface standard.

In these cases, the SBB may be little more than a vendor/technology name and version number.

E.g. if the ABB is the international FTP interface specification, then the SBB might be simply "the FTP server embedded in our Unix OS".

So, that particular FTP server component should be replaceable with minimal EA-level impact analysis and architecture change management.

The same principles apply in the human domain.

Given ABBs in the form of a logical function/capability structure, then the SBBs might be the units of a corresponding "functional organisation structure".

The EA team does not worry if the management reorganises the organisation structure, providing it can be mapped to the same logical function/capability structure.

Notes on the use of ArchiMate symbols

First, three things to know.

· ArchiMate's generic meta model is a little flaky and/or misinterpreted.

· TOGAF is based on a different generic meta model, so no perfect mapping is possible.

· People use the terms "Building Block" and "Service" to mean anything they fancy.

Note that ArchiMate’s definition of interface appears to embrace two things that may be decoupled.

· a passive interface specification (e.g. a restaurant menu)

· an internal active structure element via which services can be accessed (e.g. a waiter).

The latter might better be modelled as a business role or function rather than a business interface.

Note also that an ArchiMate interface is bound to one and only one internal active structure element, which prevents the decoupling of interfaces from components/roles.

TOGAF recommends defining an Architecture BB by its service portfolio (a potential interface).

The general relationship is that Solution BBs <realise> Architecture BBs.

Which is to say physical components <realise> logical components.

If your Architecture BB defines an Interface, then you can use the Interface symbol.

Else use the Function symbol (a logical component that ArchiMate misplaces alongside Process.)

Using the Function symbol avoids the constraint in ArchiMate that Interface acts as a façade Component to 1 and only 1 server Component.

You may use the Component symbol (since Function is a specialisation of Component).

But do not use the Service symbol, which is a contract for a discrete, unitary, behavior in TOGAF.

(Surely also in ArchiMate, though example diagrams confuse Service with Interface or Component.)

Remember, in TOGAF, Solution BBs <realise> Architecture BBs.

The relationship is realisation rather than other plausible candidates like specialisation or assignment.
(Specialisation is left to right in TOGAF’s Enterprise Continuum, not top to bottom.)

(Assignment in ArchiMate is primarily for assignment of structural elements to behavioral elements.)

ArchiMate rules won’t let you connect Interface to Component by realisation or specialisation.

Which is another reason to use the Function symbol for the Architecture BB.

Footnote: more illustrations

This table contains technology-specific examples of service portfolios, logical and physical components.

General concepts	Required Behaviors	Logical Structures	Candidate Physical Structures
Generic concepts		ABB	SBB
TOGAF elements	Service portfolios	Logical Components	Physical Components
Infrastructure Technology example	Operating System service portfolio as defined in The Open Group’s Unix standard.	UNIX OS	BSD (variations) Coherent GNU Linux. Android. Chrome OS. LynxOS MINIX. Plan 9 QNX. BlackBerry 10.
Infrastructure Technology example	App server service portfolio · Administration · Caching (perhaps distributed) · Clustering · Compression · Deployment API (perhaps distributed) · Failover · Security · SSL · Transactions · URL rewriting · Virtual Hosts · Web Services standards · Java Authentication and Authorization Service (JAAS) · Java EE · Java Management Extensions, · Java Message Service (JMS) · Java Naming and Directory Interface (JNDI) · Java Persistence API (JPA) · Java Remote Method Invocation (RMI) · Java Server Faces (JSF) · Java Server Pages (JSP) · Java Transaction API (JTA)	Application Server	Glassfish (Oracle) JBoss Enterprise Application Platform Wildfly Apache Tomcat Apache TomEE Apache Geronimo Jetty JOnAS Resin Servlet Container (Open Source) Blazix
Infrastructure Technology example	Messaging service portfolio (see table below this one) · Route messages · Convert between protocols · Convert between data types · Validate data against schema · Invoke services · Orchestrate services · Split and merge messages · Managed messages · Manage transaction · Encrypt data · Secure messages	Enterprise Services Bus	JBoss ESB Apache Service Mix Mule ESB Spring Integration WSO2 ESB OpenESB Petals ESB

This table says more about messaging service categories.

Messaging service categories
Route messages	static routing, content-based routing, rules-based routing, policy-based routing
Convert between protocols	conversion between standard communication protocols
Convert between data types	conversion between data types, formats and values
Validate data against schema	validation of data items against types in predefined data schemas or canonical data models
Invoke services	synchronous and asynchronous invocation, service mapping (locating and binding), reliable delivery
Orchestrate services	coordination of invocations within a single aggregate service
Split and merge messages	splitting and combining messages and handling exceptions
Managed messages	monitoring, auditing, logging, metering of messages (perhaps reported on a console)
Manage transactions	starting, committing and rolling back of transactions
Encrypt data	encryption and signing of messages
Secure messages	identification, authentication and authorization of ESB use