ESB.NET 6.1 Getting Started Guide(下)

4.1

Principles

The
Keystroke ESB Architecture is based upon the following
principles:

4.1.1

Business
Process Centric

The focus of the Service Analysis and
Development shall be Business Process Centric.

The ESB.NET
architecture promotes a Business Process centric view of what is to be
delivered. Although it often uses leading technologies to provide Service Bus
features, it is not molded to work well with any one specific technology.

Rather it
always has, and always will have, a Business Process Centric view on how
services are delivered.

The reason
for this is that this approach greatly narrows the margin of potential
misunderstanding between Business and IT. By design then, the potential of
delivering the wrong feature to the Business is greatly reduced. This means
requirements and design documentation can be less rigorous, as the Service
Interface is directly meaningful at the Business Process Level. Using BMPN and
the Service Definition approach, it is clear in non-technical terms, as to what
data and processing is expected to be dealt with by a particular Business
Activity Service being developed to satisfy the requirements of a particular
Business Process Step.

[Note:

As a result of this viewpoint, some things are
often viewed as technically unorthodox by many developers. This is because they
have a technological viewpoint, not a business focused
viewpoint.

Technologies come and go, and those viewpoints
too change. The business focused viewpoint advocated by the Keystroke ESB
Architecture is therefore future-proof as far as technologies go, as it is
solely Business Focused.]

4.1.2

Services

4.1.2.1

Business
Activity

Services shall focus on the Business Process
Step requirements only.

The Keystroke ESB Services Meta-Model is used to classify
services.
Keystroke
ESB only deals with Services that directly implement steps in a Business
Process.

In the
Services Meta-Model shown below, Keystroke ESB only deals with implementing the
Business Activity Services required for a particular Business
Process.

Application
and Technology Services are irrelevant to the Keystroke ESB Architecture. There
is no guidance here on how to organize these. Anything can be done as they are
in a separate logical namespace and should not be mixed with Business Activity
Services.

[eg. Things like how you access a database, how
you do lower level integration etc. are not of any concern to the Keystroke ESB
Architecture as they are application or technology related concerns. They do not
have any direct Business Process relevance.

The relevance is delivered via the Business
Activity Service.]

Figure 1 Keystroke
ESB Services Meta-Model - Basic

Figure 2 Keystroke
ESB Services Meta-Model - Extended

[Note:

This
viewpoint poses some interesting issues. For example, when exposing Business
Activity Services via WSDL, Keystroke ESB.NET introduces a concept of Dynamic
and client managed WSDL. This allows a client to define the granularity and
dependencies and regression issues required for functionality by a particular
client.

This is all
managed via service namespaces and service definitions.]

4.1.2.1

Service
Reuse

Service Reuse at the Business Activity Services
level shall NOT be an expected as a requirement of the
service

Unlike most
advocates of SOA, the Keystroke ESB architecture does not advocate a policy of
attempting to create services that are reusable.

In fact,
because the services being targeted are specific to the Business Process Step,
the onus of reuse is on the Business Process engineering/re-engineering effort
to identify any opportunities for reuse.

Service
reuse is of course still as applicable as ever at the application and technology
layers.

At the
Business Activity Services level, the focus is that the service exactly
implements the Business Process Step requirements, and is easily and directly
callable by the Business Process Step.

4.1.3

Interoperability is key

Interoperability shall be vendor and technology
agnostic, complete and via open and de-facto industry standards
only.

The
Keystroke ESB Architecture is designed to work in heterogeneous environments.

XMATIA –
Xml Message And Transport Interoperability based Architecture is a simple
summary of how interoperability is achieved.

At a
technical level then, the approach is to use only industry based standards and
protocols. There is no .NET, Java, COBOL or whatever interface or data format
that needs to be understood.

Only
Internet and Standards Based Protocols and Data formats are used. As usual,
these are separated into Transport Adaptors that decouple the technology
interface from the orthogonal Business Activity Services that the Business is
actually interested in.

For
example, TCP, HTTP, SOAP, WS-*, XML, XSD Schema etc. technologies are
used.

.NET
Remoting, RMI, JMS, MSMQ etc. are NEVER exposed to Keystroke ESB Client systems.
They are of course used internally, but can be chopped and changed without
affecting clients.

Course
grained, stateless, message based interactions with Keystroke ESB based servers
mean that the Keystroke ESB based server acts as its own
fiefdom.

Low level
transactions etc. do not cross this boundary. Once the message is successfully
delivered, the client is absolved from any responsibility and is denied all
control and visibility and as to what is happening internally to the Business
Activity Service.

4.1.4

Message
Data and XML

Message
shall be openly understandable by all interested parties, shall be course
grained and shall be self-contained as much as possible such that a single
message can be used to contain all relevant data for a particular Business
Activity Service.



Data that
enters and exits a Keystroke ESB architecture based Server’s standards based
entry points, destined for a particular Business Activity Service servicing the
Business Process Step is a single, course grained message that is directly
related to the Business Process Step being Serviced.

That is,
there is no low level technical or application specific data being
transferred.

A generic
Message Envelope is used to encapsulate and organize all of this data in a
manner meaningful to a Business Person and also directly understandable by the
target Business Activity Service. The exact implementation of this Message
Envelope can be tailored as required to serialize to any format required for
interoperability with other systems, however the implementation of the Message
Envelope processing code must conform to an interface that details the relevant
data requirements imposed by the Keystroke ESB
Architecture.

The Message
Envelope contains a manifest that details the message metadata. It contains high
level addressing information if required, the Message Exchange Pattern being
used, details about the documents in the Message Envelope (eg. XSD Schema
namespaces ) and references to any attachments to the message, and any other
custom data required.

4.1.5

Transport

Data
transportation shall be completely orthogonal to Business Activity Service
processing.



Purpose
built standards protocol based Transport Adaptors are used to move messages
around. This architecture allows routing messages across
servers.

In simple
scenarios, it serves as the endpoint to which a client can send a message to a
server. In more complex scenarios, it provides the low level plumbing required
to be able to do things like message routing to services based on DNS type
lookups.

For
example, in a federated scenario where Message XYZ is sent to any Keystroke ESB
compliant server, and specifies it is looking for a service in the namespace
a.b.c, a DNS lookup can be done to identify the relevant ESB Service Domain and
forward the message to the ESB Service Domain’s entry point servers using a
Transport Adaptor. Once the message enters this ESB Service Domain, it can be
again routed to a specific server within that domain using the same transport
adaptor.

This model
makes use of already existing, cheap and proven technology (DNS) to handle the
complex problem of service brokering, reliability and
performance.

Rather than
having expensive and architecture limiting service brokers, an organization can
deploy a DNS routing handler and relevant transport adaptors on each of their
ESB servers and then make use of the scalable DNS to make light work of the
complex ESB distribution and federation issues.

4.1.6

Distributed

The
Service Bus shall be completely decentralized, however provide a unified view of
all activity.



Distributed
and Centralized logging provide a unified view of all service
activity.

All ESB.NET
Servers are relatively lightweight servers. They consist of an open, fast
service execution engine with just the functionality required to scale up, out
as well as the functionality required to allow a distributed and federated
deployment with single view of all service activity to make management
easy.

Transport
adaptors make message routing a breeze, whilst the simple and distributed
logging features mean that each instance is responsible for logging their
activity to wherever it is decided is best.

Logging of
local activity to a local database means a particular node or instance’s
activity is easily managed, whilst also logging this activity to dedicated
centralized servers, means that this activity can be viewed and managed
centrally, as well as added to a data warehouse for more detailed off-line
analysis.

Log Enquiry
Services mean that you can get also get a distributed view of logs from a
particular service instance that stores only its own data, by having it query
other servers for their log data into a unified view.

4.1.7

Federated

Service
Bus Federation shall be completely scalable and reuse existing, proven
approaches.



Service
Domains allow the logical partitioning of your ESB into the business areas most
relevant to your deployment.

Service
Domain and Service Domain Entry Point servers can be transparently configured
and govern the logging of data. All are transparently scalable via Network Load
Balancing technologies, so scalability is practically
limitless.

DNS can be
used in larger deployments to manage complex service routing
issues.

Servers in
a particular Service Domain provide services to catalog the services available
to the specific service domain, so the service registry is truly dynamic and
completely federated. It does not require any additional servers or applications
unless governance is to be introduced. Even then, it can be transparently
applied to Service Domains of choice rather than being a fully centralized and
bureaucratic model.

4.1.8

Analysis

Analysis
shall be available for all Service Activity.



All log
activity can be both queried at runtime as well as offline in a data warehouse
for more complex analysis.

Custom
Service Handlers can be added to add custom Business Activity Monitoring
filters.

4.2

Overview

ESB.NET is
a lightweight, distributed Enterprise Service Bus.

It is an
implementation of the Keystroke ESB Architecture. As such, it follows all the
Keystroke ESB Architecture Principles.

ESB.NET may
seem cumbersome at first, but if pursued, it quickly lets you realize the
Keystroke ESB Architecture’s benefits, with very little effort in relation to
the rewards reaped.

ESB.NET
uses a federated broker pattern/messaging paradigm, and receives requests on a
single endpoint for each node in the federation tree (OK, an endpoint for each
transport being used – eg. Raw HTTP, SOAP (types of SOAP implementations
etc.)).

This gives
the benefits of a Broker, without the typical drawbacks of Broker bottlenecks
for development, deployment, runtime performance & scalability
etc.

As such, it
can scale to internet level size and performance.

You can
also add Routing Components to add high performance and complete Service
Endpoint Location Transparency on top of Service Virtualization for asynchronous
requests. This adds though, latencies between node hops.

Synchronous
requests can still achieve high performance and scalability, however they are
restricted to either using a Convention for the Service Endpoint Location, or
fallback to configuration and Synchronous Routing with the associated
scalability restrictions thereby imposed.

The
following sections cover the very basic details of the ESB.NET Architecture,
using the TOGAF and Zachman Architectural Methods terminology as appropriate.

4.3

Business
Architecture and Service Domains

The need…
Business Oriented Service Development

4.3.1

Business
Activity Service Development Process

Focus on
Business Process

Understand
and adhere to Services Meta Model

Activity
Service Definitions as per target Business Process

Partition
Services into Business Specific Domains

4.3.2

Use
Cases

4.3.2.1

Analysis

Business
Process Analysis and Service Identification

Service
Definitions

4.3.2.2

Design

Service
Definition Elaboration

4.3.2.3

Development

Service
Implementation – as per Service Definition

4.3.2.4

Service
Implementation

4.3.2.4.1

Service
[Development and] Configuration

4.3.2.4.1.1

Synchronous

4.3.2.4.1.2

Asynchronous Client

4.3.2.4.1.3

Asynchronous Service

4.3.2.4.1.4

Asynchronous Client and
Service

4.3.2.4.1.5

Orchestration

4.3.2.4.1.6

Events, Publish and
Subscribe

4.3.2.5

Service
Deployment and Provisioning

4.3.2.6

Service
Support and Maintenance

4.4

Information Architecture

4.4.1

Messages

4.4.1.1

Envelopes

4.4.1.2

Business
Information/Data/Domain Schemas

4.4.1.3

Service
Schemas

4.4.2

Validation

4.4.2.1

Structural and Data
Types

4.4.2.2

Constraints – Cardinality, Regular Expressions,
field lengths

4.4.2.3

Rules

4.4.3

Transformation

4.4.3.1

Structural

4.4.3.2

Classification Code
Values

4.4.3.3

Rules
(Derived values)

4.5

Application Architecture

The ESB.NET
application architecture …

4.5.1

Logical
View

4.5.1.1

Static
Models

4.5.1.1.1

Plug-In
Services

4.5.1.2

Behavioral Models

4.5.1.2.1

Activity
Diagrams

4.5.1.2.1.1

Synchronous


Sequence
Diagram showing a Synchronous Service Invocation via the Sequential Workflow
Adaptor.

Note that
non Sequential Workflow Services are invoked in a similar
manner.

Usually,
the Pipeline Manager will invoke them directly.

If using
the ConventionOverConfiguration Application Adaptor, that class will sit
straight after the PipelineManager.

If the
Service is a Sequential or State based Workflow, it will be invoked via the
Relevant Sequential or State Based Workflow Adaptor.

Generally,
the Order of invocation is in the following order & hierarchy
scope:

v

<TransportAdaptor>HTTP,
WCF, WSE3…variants and
WCF
profiles
…

Ø

<Kernel>ContextManager

§

<Kernel>Context

·

<Kernel>SystemEntryPointManager

¨

Specific SystemEntryPoints -
Optional -
Create/
Configure

·

<Kernel>PipelineManager

¨

<Application
Adaptor>ConventionOverConfiguration –
Optional -
Create/
Configure

Ø

<Application
Adaptor>Sequential or State Based WorkflowAdaptor –
Optional -
Create/
Configure

§

<Service
Adaptor/Handler>The particular service being invoked…i.e. YOUR SERVICE CODE
(could be multiple depending upon your
configuration.)

The Rainbow
(R
O
Y
G
B
I
V
[or R
O
G
B
P
]) colour scheme,
indicates the increasing likelihood that you will be creating code or modifying
configuration parameters in that particular area, or configuring these service
filters/handlers in/out.

Red	Very unlikely that you will be generally writing any code here (seeing as it’s the ESB.NET Kernel code)
Orange	These are ESB.NET shipped Adaptors that leverage the ESB.NET Core Kernel functionality to add value.
Green	These are potential points where you can add value/customize ESB.NET for your particular environment & requirements. For example, you may create new WCF profiles, add a completely new transport, add new SystemEntry/ExitPoint processors, or simply configure in/out the existing ones (eg. SQL or MSMQ EntryPoint).
Blue	Configuring in/out Base ESB.NET Services
Purple	The common services you write on a day to day basis.

Optional
handlers are based upon specific service configuration.

Also, any
“AlwaysExecute” configured handlers will be invoked before/after your service,
again, depending upon specific configuration.

Sequence
Diagram showing a Synchronous Service Invocation via the State Based Workflow
Adaptor.

Note that
the sequence detail before the PipelineManager are the same as for the
Sequential Workflow Adaptor above.

The above
sequence diagram shows 3 areas of processing:

1)The
Initial Workflow Runtime Initialization

2)The
Creation of a Particular Instance of a
Workflow Type

3)The
Updating of a Particular Instance of a Workflow Type

4.5.1.2.1.2

Asynchronous Client

4.5.1.2.1.3

Asynchronous Service

4.5.1.2.1.4

Asynchronous Client and
Service

4.5.1.2.1.5

Orchestration

4.5.1.2.1.6

Events, Publish and
Subscribe

4.5.1.2.2

Sequence
Diagrams

4.5.1.2.2.1

Service Invocation
Patterns

4.5.1.2.2.1.1

Synchronous

4.5.1.2.2.1.2

Asynchronous Client

4.5.1.2.2.1.3

Asynchronous Service

4.5.1.2.2.1.4

Asynchronous Client and
Service

4.5.1.2.2.1.5

Orchestration

4.5.1.2.2.1.6

Events, Publish and
Subscribe

4.5.1.2.2.2

Post-Processing

4.5.1.2.2.2.1

Data Warehouse

4.5.1.2.2.2.2

Business Activity
Monitoring

4.5.1.2.2.3


4.5.1.2.3

Plug-In
Services

4.5.2

Physical
View

4.5.2.1

Static
Models

4.5.2.1.1

Deployment Diagram

4.5.2.1.1.1

Management Console

4.5.2.1.1.2

Service Bus

4.5.2.1.1.3

Database

4.5.2.1.1.4

Instances

4.5.2.1.2

Component
Diagrams

High Level Component Diagram

Component Summary

4.5.2.1.3

Class
Diagrams

Class Diagram of Send Transport Adaptors

Class Diagram of Pipeline Management

Class
Diagram of Pipeline Manager Detail

Class Diagrams of Envelopes and Provider Model

Class
Diagram of Managers:

Context
Managers, Contexts, LogManagers, SystemEntryPointManager and System Entry
Points.

4.5.2.1.4

Plug-In
Services

4.5.2.1.5

User
Interface

4.5.2.2

Behavioral Models

4.5.2.2.1

Sequence
Diagram

4.5.2.2.1.1

Synchronous

4.5.2.2.1.2

Asynchronous Client

4.5.2.2.1.3

Asynchronous Service

4.5.2.2.1.4

Asynchronous Client and
Service

4.5.2.2.1.5

Orchestration

4.5.2.2.1.6

Events, Publish and
Subscribe

4.5.2.2.2


4.5.2.2.3

Plug-In
Services

4.5.2.3

4.6

Technical
Architecture

Suggested/Reference ESB.NET Deployment
Architectures

4.6.1

Reference
Simple technical deployment architecture

4.6.2

Reference
Federated technical deployment architecture

5

Operations

6

Maintenance and
Support Considerations

FROM:http://keystrokeesbnet.codeplex.com/