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/