ESB governance is a multi-faceted issue, and can
become complex depending on the runtime management requirements and the
necessary involvement on an organizational level.
What provisioning ESB-hosted services entail will vary by enterprise, but typical requirements are:
advertising service availability (service registry or repository)
implementing monitoring of messages based on type or services
creation of custom on-ramps
definition of security policies
The ESB Toolkit does not add a
governance layer onto BizTalk or the .NET framework. It does, however,
have hooks into some third-party governance solution providers in order
to integrate their governance capabilities into a BizTalk-based ESB. In
addition, service virtualization solutions, such as the Managed Services
Engine (available on Codeplex) can be used as containers for on and
off-ramps, allowing policy-driven enforcement of SLAs or tracking at the
container level.
When creating a governance plan for your ESB implementation, there are some key considerations to take into account.
SLA Enforcement
Service
level agreement (SLA) enforcement means confirming that an agreed upon
service level (such as response time or availability) is being met. If
you are going to monitor service metrics, there are two common models
used:
observation model
container model
In a Microsoft context,
the observation model could mean instrumenting the service using
BizTalk’s BAM capabilities .
Essentially, tracking of events (for example, service start) can be
monitored and subsequently reported on. This model can easily be applied
over various transport protocols, although it will only capture data
you need to provide the logic to respond to conditions outside of the
SLAs.
Using the container model is
similar, but takes a slightly different approach. The proxy is invoked
at the consumer-side of a Web service call. It registers metrics, but
can also perform other functions, such as usage metering and service
virtualization.
Monitoring
Monitoring of an ESB breaks down into three distinct areas:
infrastructure monitoring (machine health)
ESB component monitoring (ESB health)
custom application and service monitoring (solution/service health)
The first is the server
health type of monitoring that is provided by tools such as Microsoft
System Center Operations Manager and IBM’s Tivoli. This is the lowest
level of monitoring in that it provides confirmation that the server is
running and specific services are operational through to CPU and memory
utilization. In a well planned environment, these tools can give you the
ability to not only monitor changing server conditions, but to also
react to them and re-assign resources as required.
The next level is
concerned with the monitoring of ESB core services and components. At
this level, you can leverage BizTalk’s BAM capabilities to track service
metrics .
Metrics gathered can include historical trend data, allowing server
administrators to spot service latency degradations and other trends
that may not be readily apparent from a tabular listing. Furthermore, if
you are using BAM scheduled aggregations, the data will be collected in
SQL Server Analysis Services OLAP cubes, which allow
for new views into service metrics to be created long after the metrics
data has been collected. Both the ESB Toolkit and the Managed Services
Engine utilize BizTalk BAM for this type of monitoring. In the case of
the ESB Toolkit, tracking activity for part of an itinerary is as simple
as enabling tracking on that step, and then reporting on it.
Lastly, other
applications and services created in an enterprise, but outside of the
realm of the ESB core services, can also take advantage of the metrics
tracking infrastructure provided by BizTalk BAM.
Preparing Project Teams
Moving to an ESB topology
marks a fundamental change for most enterprises, as it can involve
deploying a completely new infrastructure along with new development and
administration requirements. In order to ensure a smooth transition, it
is essential that care and consideration be paid to the soft aspects.
Specifically, any transition plan should include:
training and consulting
developer tools and SDKs
Training can take many
forms. Formal training is generally encouraged given the range of
technologies and architectural complexities that can be part of BizTalk
Server and ESB Toolkit implementations. Also, you can help reduce common
risks by planning and carrying out the initial steps of a transition
with the guidance of experienced consultants.
Appropriate
developer tools and SDKs can help technology architects and developers
work hands-on with BizTalk components and services prior to entering
actual project delivery stages. It can further help highlight where
additional, non-Microsoft tools and technologies can be incorporated to
ensure that the ultimate ESB architecture is in support of an overall
vendor-neutral service-oriented architectural model.
Finally, ensuring that
any plans, architectures, and infrastructure deployments for a specific
ESB implementation are in alignment and encompassed and appropriately
positioned with an overarching SOA governance plan is essential to
ensuring that the eventual ESB implementation will not unintentionally
establish a silo of its own.
