ESB.NET 6.1 Getting Started Guide-优快云博客

All information contained in this document is confidential to Keystroke IT Australia and is intended for use only within Keystroke IT Australia. No part of this document may be reproduced by any means, nor transmitted, nor translated into a machine language or other language without the permission of Keystroke IT Australia.

1.2 Foreword

This document is delivered by Keystroke IT Australia as part of ESB.NET.

1.3 Abstract

This document gives an Overview of an ESB and how to build one. It covers the Principles of the Keystroke ESB Architecture and sets the scene for the need for ESB.NET. ESB.NET is positioned as a framework to deliver ESB type capabilities for the .NET Platform.

1.4 Document Control

Action	Name	Role	Date	Signature
Compiled by	Minas Casiou	Solution Architect	05/04/2008
Approved by
Authorised by
Accepted by

1.5 Distribution

Role/Department	Location	No. of Copies
Keystroke Team

1.6 Amendment Record

Issue Status	Version	Date	Actioned by	Description
Draft	0.3	15/06/2008	Minas Casiou

1.7 Document References

Note that most documents are incomplete and are updated regularly.

Name	Description
Keystroke ESB.NET Services - Installation Guide.mht	How to Install ESB.NET
Keystroke ESB.NET Services - Tutorials - Common Scenarios Overview	Basic Coverage of ESB.NET Service Implementation Scenarios
Keystroke ESB.NET Services – Tutorials *	Cover how to implement Common ESB Scenarios using ESB.NET
Keystroke ESB.NET Services - Features - BSDL	Business Service Definition Language
Keystroke ESB.NET Services - Developers Guide	Implementing Services with ESB.NET

*Note that this is an ever-growing list of Tutorials. There is one document for each tutorial.

2 Abstract – BPM, SOA and ESB’s

As with any major initiative, implementing a service bus within an Organization starts with a way of thinking that’s shared amongst key stakeholders.

Any degree of vagueness makes this shared vision a blur that’s likely to fail.

Until such time that concrete reference implementations are ubiquitous, SOA and ESB’s will not be for the feint hearted, and are likely to be implemented sub-optimally.

There are a couple of ways to avoid this problem, each premised upon having at least one knowledgeable, visionary and strategically placed resource that can make it happen.

Each option has its own set of challenges of course - there is no silver bullet, just great satisfaction.

First, here are some seemingly innocuous approaches to implementing an SOA in an organization.

2.1 Seemingly viable SOA Implementation Options

2.1.1 Option 1 - By stealth/individual (bottom up)

This approach entails, 1 or a small number of individuals well versed in SOA, Technologies and Architecture in general, take it upon themselves to ensure that the Solution Architecture for each project that is implemented in an organization is based on some core SOA tenets that they deem to be necessary.

Their motivation is personal excellence, and is brought to fruition by extra-ordinary, out-of-band personal commitment.

This personal commitment is necessary to get a base framework together that does not address any directly measurable business needs, as there is essentially no formal time and funding allocated to it.

Obviously, this is not an option you can realistically advocate for SOA.

2.1.2 Option 2 - By consensus (top down)

This approach entails Business & Technology buy-in to SOA and an Enterprise Architecture, with explicit expectations on some sort of ROI across the Business and IT spectrum, in terms of long term savings as well as Business and IT agility.

Given the number of times Business has been promised the “Next Big Thing” by IT, followed by subsequent failure, this is always a tough sell to the Business as well as IT.

2.1.3 Option 3 – Buy a product and vendor consulting that claims it’s an ESB and that follows SOA principles

This approach is often a consequence of Option 2 above.

Unfortunately, most vendors are not particularly well placed to provide an answer.

After sucking up a lot of licensing and consulting revenue, SOA/ESB focused vendors will often deliver nothing more than some EAI functionality masqueraded as SOA.

The SOA landscape still being defined and on its own, its definition and value proposition is still often unclear.

2.2 Why are these options then so flawed?

When SOA and ESB’s were first coined as terms in IT, they were aimed at identifying, naming and qualifying a general IT and Business problem.

Unfortunately, this is often not conveyed across, and the SOA/ESB value is therefore left in limbo. After doing all this (whatever it is that SOA supposedly is supposed to be), how do we know if we’ve done it right?

Does the fairy Godmother take the SOA from underneath our pillow and replace it with a silver coin?

Do we get some tick by the system administrators that these now seemingly over-engineered services are actually providing us with some technical insight as to what’s happening at the business level?

Do we know we’ve done it right when we start re-using some services across different scenarios?

How do we know what we’re supposed to do, and how do we know we’re doing it right?

Why the heck should we even bother?

2.2.1 BPM, CRM, Business Benefits

Where’s the BPM? Where’s the CRM, where’s the Business Benefit???

The reason we’ve got the SOA and ESB terms, and the reason for them being, is that they address the lower level detail and implementation of Business Process Management.

Alone, to an Organization, at the Business level, and hence it should similarly follow at the IT level as well (seeing as the sole purpose for IT existing is for the actual Business…), SOA and ESB’s are just as meaningless as a network and a computer.

It’s when they add some sort of Business value that they start to become interesting.

The way they become interesting is by allowing an Organization to relatively unambiguously, express the Business Processes important to that Organization, and allow them to effectively execute those Business Processes as well as being agile enough to meet any changes to those Business Processes in timeframes relevant to the Business (may be 1 hour, may be 2 years… whatever is sensible for the Business).

The reason SOA and ESB’s and Common (or Canonical) Information Models are not very well understood, is because they’re looked at from a purely technical perspective.

This is analogous to a network without a computer, or a computer without any inputs.

Yeah, it does stuff, but … what’s the point?

How do we know if the network is any good? The routers seem to be moving packets around, the firewalls seem to be blocking ports…

Success I guess…..right?

Err…how do we know?

If no computers are using it, we have no idea if the network is any good. If we’ve built an SNA based network when all our computers talk TCP/IP… then, it doesn’t matter how good the network is at SNA, it’s completely useless to us.

Similarly, if we’ve got the best computer hardware and software, but there’s currently no external interfaces (human, network etc.), then what good is it?

This is the problem with SOA/ESB’s, CIM when not viewed in light of BPM, CRM and other Business oriented facets.

3 How to Deliver and ESB

3.1 ESB Purpose - BPM, CRM and Business Benefits should be at the heart of any SOA/ESB and CIM initiative

Unless SOA, ESB’s and CIM are viewed in light of Business Process Management, Customer Relationship Management and other Business Oriented Benefits.

i.e. How they are to be used to implement/compliment BPM, CRM and add value to the Business, we don’t know what problem we’re addressing, and hence whether we’ve successfully done anything with the ESB and our SOA.

Until an ESB built using SOA principles is used by specific Business Processes and benefits relating to the Business Process are delivered, in areas such as say,

· Business Process implementation

· Agile Business Process Re-Engineering, change of rules etc.

· Insight via real-time Business Activity Monitoring historical data analysis to arrive at meaningful information that can be used to improve Business Process performance

· Customer Relationship Management

· Improved proactive and reactive responses to important Business issues

then whether the SOA and ESB implementation was at all successful cannot even be seriously be contemplated. It just ends up being another part of the generally dizzying array of IT legacy.

The CIM argument is equally useless unless the CIM is understood by the Business users, and used by many Business Processes in order to gain from re-use of the CIM entities & schemas.

SOA should therefore, not be judged by

· whether a particular web service or operation is re-used.

· whether the service is using UDDI or other mechanism to look up the service endpoint.

· how fast it runs a data transformation, or by how it has some pretty drag and drop functionality for doing data mappings.

· how quickly a client can point to an endpoint and invoke the service.

Nor should it be directly judged by compliance to specific standards or how it uses those standards. Standards are a means to an end – they are not the end.

These are technology specific measures. They do not have any direct Business meaning or benefit.

Of course, the more of the above technology specific measures that the SOA implementation adheres to, the more amenable it is to re-use, robustness, productisation etc., so they are obviously all very important technical aspects of an SOA, ESB and CIM implementation.

They do not, however, directly make the SOA/ESB/CIM a success.

It’s whether the Business Perspective’s measures have been met that determines success, not the Technical Perspective’s measures.

3.2 ESB Implementation - Standards, Capabilities and Protocols should be at the heart of any SOA/ESB and CIM initiative

At ground zero, here are a number of reasons ESB’s go wrong:

3.2.1 This is what NOT to do in trying to implement an ESB:

· Do NOT pick a particular Product and bet your ESB on it

· Do NOT pick a Vendor and leave it to them

· Do NOT put a Centralized Physical Layer in the middle of Clients/Services (aka EAI) and expect it to solve all your problems

· Do NOT confuse Logical Models with Physical ESB Models

· Do NOT deliver it as a single project

· Do NOT have a central group responsible for long term delivery, maintenance of the deliverables (Software, Hardware, Network etc. of the ESB).

3.2.2 This is what you SHOULD to in order to successfully implement an ESB:

In essence, there are only a handful of relatively simple things you should do, however, they are instrumental to the success of an ESB initiative, and hence must be done well:

· Specify what services/capabilities you want an ESB to have

o Make up a general list of capabilities that sound right

§ (see OpenStandards Presentation - BPM IMPLEMENTATIONS USING SOA, CIM's AND ESB's for examples)

o Use this list as inspiration to try and identify the capabilities are especially important, useful or “nice to have” in your organization

o Have an ongoing process – this needs to live as long as the ESB lives. The Organization must never lose sight of this list of capabilities. It is the key driver of everything an ESB means to your Organization. Forget about everything else that you’ve ever heard or read about what an ESB is & what it should do etc. For your Organization, this list is ALL that matters.

o Classify the items in terms of priority, and review them periodically as you deliver them, and as the Organization’s requirements evolve over time. Review industry best practices and add the applicable ones to the “one big day” list. This will give you an idea of what you’ve got up your sleeve if something comes out of left field. Move them up/down the priority stack as required. On the “Next To Build” list, aim to have one or two capabilities at a time.

o Only build what you’re going to use. This ensures they are well tested. Ensure they are VERY stable. If not stable, re-visit, re-build and proceed. Unlike any other software in the Organization, the ESB implementation cannot afford to be loose. It must be the leanest, most stable, most understood part of the Organization’s Software assets. For this reason, try to keep it as simple as possible, with each capability having REAL requirements and benefits.

· Have a Committee to manage the common capabilities list. Other features can be added by minority groups and used within their realm (or Service Domain etc.).

· Have implementations of the above capabilities in whatever platforms are strategic for your Organization.

For example

o .NET if you’re a .NET shop

o Java if you’re a java shop

o Both if you’re a both a Java and .NET shop

Anything else viable on whatever platforms you have

o Mobile

o Mainframe

o …

· Use the Internet as inspiration. Leverage as much of Internet related concepts, protocols, software etc. as possible. Don’t come up with your own implementation until you’re sure there’s no equivalent of it in the internet space. This approach helps guarantee your ESB will scale in many ways:

o Multiple stakeholder Buy-In

o Development, Delivery, Operations & Maintenance

o Performance

o Availability

o Sustainability

o Knowledgeable persons, useful & reusable knowledge transfer, easily available (commodity) skill sets

o …

· Treat the ESB as a logical (and very rich & wide) Layer 8 to the ISO’s OSI Network Model. Make it a layer by which any ESB competent node can deliver what functionality is required by the IT department of an Organization.

o That’s what the BUS in the Enterprise Service BUS is intended for. It’s a protocol which when implemented, allows for any node to interoperate with other BUS aware nodes. This may be in a centralized or hierarchical manner, or in a peer to peer manner depending upon the capabilities required & mechanisms chosen.

o A common mistake is to treat an ESB as a central point for applications to connect to. That model quickly encounters scalability & logistics problems. Logically, an ESB layer is one that sits between service providers and consumers. Physically, it should be a layer that allows ESB aware applications to converse. Unfortunately, the OSI model has not been extended to layer 8 as this area of IT has been dominated by application frameworks and vendor technologies. The industry has ripened and the time has come for Organizations to build their own OSI layer 8. Over time, a standard set of OSI Layer 8 specifications and implementations will prevail. The WS-* is a step in this direction, however it is too all-encompassing (focusing more again on delivering existing application level constructs into a Standards-Based set of technologies), and does not deliver on simple, free & pluggable, transparent ESB qualities that Businesses require. We still have disparate messaging, integration and data transformation technologies – because vendors can still make money here. What Businesses would like, however, is to be able to have all their systems have basic capabilities to effectively communicate. Business (especially big Organizations) would be happy to buy (usually at whatever premium) systems that have a standard basic communication capability with other systems. i.e. ESB like qualities baked into applications. Unfortunately, we are nowhere near that. One of the purposes of ESB.NET deployments is to have it sit in front of specific applications and provide this capability.

· In each platform, start with a framework that’s very flexible. Have people that are passionate about each platform working on the ESB framework for that platform.

· Build a platform that can be refined over time, is well understood and is easily changed over time. Try to keep it as simple as possible.

· Have a low barrier to entry (within reason). This obviously ties in with the required capabilities

· To start with, build a single capability in each platform at a time. Obviously, things like connectivity are the most basic and important of all. To lower the barrier to entry, pick standards based protocols as much as possible.

· Avoid niche products, standards, protocols etc. as much as possible. Conversely, you may have to taint some standards or protocols to make them easy or useful to your requirements. Better that than to come up with something completely new.

· Base everything on evolution. Revolution is not required. We’ve pretty much got most of the technologies we need. We just need to apply them sensibly. Undoubtedly, this will be the most difficult task.

· Whenever using a product, search for the capabilities in the above list. Ensure the product is extensible enough to enable you to deliver on the above capabilities.

o Aim high

o Deliver low

o Deliver wide

o Get everyone involved

§ All of IT System Aspects

· Business Stakeholders (the Business needs to know what they’re spending their money on, and what features & capabilities they’re investing in)

· Service Producers

· Service Consumers

· Business Applications/Systems representatives

o Measure/Understand the benefits & progress

o Repeat the above till you have the basics in place. The process should then take care of itself.

· Encourage multiple implementations of the capabilities. Have a reference implementation for one platform and a set of conformance tests that any ESB capability producer should pass.

o An ESB Nirvana would be that ALL systems in your Organization can natively support your ESB capabilities. To that end, aim for lightweight (or possibly even embeddable), distributed & federation capable implementations so that they can be deployed as close as possible to each system in the organization.

· Have STRONG Governance of the ESB capabilities and teams claiming to be delivering the ESB capabilities. Although measurable conformance tests need to be passed, the principles behind the ESB should also be evaluated. Never let a single application or group bully the ESB effort by pushing a particular technology or product. Conversely, the Governance board should be open minded & platform neutral.

4 Keystroke ESB Architecture

It cannot be stressed enough how important getting into the mindset of the above abstract is.

With the above in mind then, the following gives a brief overview of the Keystroke ESB Architecture.

It is presented here to set the scene for what is to be expected by a Keystroke ESB.NET deployment.

It is key to understand the paradigm shift away from the traditional technology focused approach, and that approach toward the focus on Business that Keystroke ESB.NET advocates, as this has notable ramifications to an organization planning to deploy ESB.NET as part of their services platform. Although ESB.NET can work pretty much transparently in many scenarios, its full benefit is only realized when the intent of the Keystroke ESB Architecture is fully understood and implemented with the key principles of that intent in mind.

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