从性能角度分析Biztalk Server在SOA技术栈中的角色

By Saravana大牛:http://blogs.digitaldeposit.net/saravana/post/2009/03/04/SOA-where-will-BizTalk-Server-fit-in-the-technology-stack-(from-performance-perspective).aspx

转载理由:从SOA整体解决方案的高度，结合SOA服务性能，服务层次，服务粒度，服务层次协议等角度阐述了Biztalk Server在SOA中的角色。

Introduction:

NOTE: Opinions expressed in this article is from my own perspective. 

There are various definitions available for Service Oriented Architecture (SOA), the basic idea is to avoid building new applications from scratch each time and also to avoid duplicating applications, and data and business logic in one part of the organisation that already exist in another part of the organisation. Instead, applications are built quickly out of existing building blocks called services, and draw information from different places throughout the organisation without actually changing where the information lives. The biggest benefits of properly implemented SOA are greater business agility, better responsiveness to customer and market demands, and significant cost reduction.

Agility is often promoted as one of the biggest benefits of SOA – an organization with business processes implemented on a loosely-coupled infrastructure is much more open to change than an organization constrained underlying monolithic applications that require weeks to implement the smallest change.

Objective: To answer the question, Is BizTalk Server a better fit to build coarse-grained business services layer in a low-latency scenario, or are we better off building them in a traditional way using .NET/JAVA.

A typical SOA implementation will look like this:

This picture is going to be key reference point for all the discussions that's going to follow. Let us see various layers in brief here:

Fine-Grained (Application) Services:

The starting point of SOA initiate is to build some fine-grained application services on top of your existing assets. A fine-grained service performs very specific tasks. As such they can’t solve any major business problems, they are more like system level API’s.

Example: getFund, getFundByWrapper, getFundByCategory, getFundByProductRange, getFundByClient

getFund operation for example just list the list of available funds in your organisation, it may take some additional parameters to filter the results. Of its own it normally doesn’t add much value to the business.

Coarse-Grained Business Services:

Majority of the time, the services exposed from core systems at fine-grained level are too granular, to meet the needs of the business applications or processes. In such cases, it is often necessary to orchestrate multiple fine-grained services with additional business logic. In this process, called service orchestration, a new set of business services are created that is much more useful to a variety of business applications, abstracting the technical complexities underneath.

Example: CreateClient (ClientDetail client), CreateAccount (AccountDetail detail), CreatePayment (PaymentDetail detail)

CreateClient for example can interact with set of fine-grained services like (validateClient, getFund, validateAccount etc). This operation can be used in isolation if required, which solves the business problem of creating client.

Composite Services (Business Process Layer):

In many organisations there will be a requirement to put a composite business process layer on top of the coarse-grained business services layer to solve variety of business problems. These new applications (services) are the result of a process called application composition, and are known as composite services. Composite services are created in a modular way by combining various business services available both inside and outside the enterprise.

Example: ProcessInvestmentApplication(InvestmentDetail detail)

This operation will solve a Business Issue. It can take an application form and process it end to end by calling various underlying coarse-grained business services, which internally will call fine-grained application services.

Technology Stack:

Technology Stack you see on the right hand side in the picture is completely irrelevant to SOA initiative. There are lot of misconceptions in the industry about SOA

1. You can buy an off the shelf SOA product and make your enterprise SOA capable.
2. SOA is all about web services. Its true web services play a key role in SOA initiative, but they are clearly different.

There are few more, but I’m not going to go in detail. The main take away here is “technology is irrelevant to SOA adoption”, choose the right technology which is best for your organisation. The technology you have used inside your organisation and the technology your in-house developers/IT professionals are familiar with. That doesn’t mean you need to stick with what you have, be brave enough to explore the boundaries, see what value a new product in the market can bring to your organisation. The best thing about SOA is you can “mix and match”. Your fine-grained service can be build using JAVA/Web Sphere, your coarse-grained Business Services layer may be build using Microsoft Windows Communication Foundation (WCF) or BizTalk Server orchestrations, your top level composite services can be build using Microsoft BizTalk Server or SeeBeyond or TIBCO.

But it’s vital you choose the right technology for the right layer. In this article I’m going to focus where using BizTalk server will be appropriate and some performance considerations.

Where will BizTalk Server fit in the technology stack?

Disclaimer: The options provided here are my own based on our implementation and experience. It may change from organisation to organisation. Please treat this as an information only source.

In a SOA infrastructure the life expectancy of the services will move from short lived system services to long running business process when you move higher up the layers. Performance, Management, Maintainability and scalability issues will all increases in proposition as you move higher up the layers. A need for middleware product like BizTalk will arise when the services start to live longer in your environment.

1. Building fine-grained System Services:

BizTalk Server won’t be suitable for building fine-grained system services.

Fine grained services are normally built for specific “fit for purpose” scenarios. They normally won’t have any complex business process involving multiple external services; also in general they will be very short lived. Fine-grained services will be the one interacting with your legacy systems like databases, calling middleware business components (COM/ .NET components etc) that have been around for years and years within the organisation.

You need to adapt a technology which got less overhead, Example: ASP .NET asmx based web services, Windows Communication Foundation (WCF) based services, and JAVA web service will all be perfect fit for building fine-grained services.

In some cases the fine grained services will be exposed using the tool provided by the corresponding providers. Example: SQL Server HTTP endpoints, SQL Server Data Services (SSDS for on-premise SQL Server databases), SAP, JDEdward etc got the ability to expose as web services.

This is the layer where you can consider options like caching to improve performance.

2. Building coarse-grained Business Services:

BizTalk Server will be better candidate for this layer, some consideration need to be given in the way you architect your solution to cater for performance. Sometimes it will be debate whether to use BizTalk (or any middleware product) in this layer.

Following is one of the common patterns you’ll see on a Business services layer, aggregating various fine-grained services with some additional business logic and responding the result to the consumers.

With the presence of powerful

• Orchestration engine,
• Rules engine,
• Transformation engine,
• Easy/secured endpoint configuration,
• Ability to expose business process as web service,
• Support for various WS* specification out of the box by providing Windows Communication foundation (WCF) adapters both for publishing/consuming,
• Out of the box tracking and monitoring capabilities,
• Easy management (example: orchestration designer combined with rules engine for each business process management),
• Support for long running transactions, compensation, etc., etc.

BizTalk Server will be a better fit for this layer.

3. Building Composite Services - Business Process Layer:

BizTalk Server will be THE best candidate for this layer.

All the points mentioned in building coarse-grained business services layer with BizTalk Server still applies to building the composite business process layer. Normally in this layer the process will be long running. BizTalk Server will be THE best candidate for building composite business processes.

Performance Considerations in SOA:

One of the biggest questions that arise on an organizations SOA initiative is the performance impact of adding a middleware product like Microsoft BizTalk Server.

1. Layers (abstractions) Vs Performance:

Enterprises normally take a bottom-up approach for their SOA initiative. From the above figure you can see the number of blocks starts to reduce when you move closer to the Business Domain. The saturation point will dependent on the efficiency of the business application as well as how coarse or fine grained the services are as they exist within the SOA. In some situation it will be sufficient to stop at “Coarse-Grained Business Services” layer; in some you may need additional layers like “Composite Services – Business Process Layer”.

Layer abstraction is good for business, because it masks the complexity of the underlying technology implementation while presenting composed business services. But every abstraction comes at a price, and the services abstraction is no exception. For limited sets of services with small numbers of users, this performance hit may be minimal. For SOA implementations with large numbers of users (with varying profiles), services, or traffic, however, maintaining the necessary performance levels presents a substantial challenge.

It’s a no brainer; more the number of layers you have, the performance are going to suffer. Also, on SOA initiative the standards adaption like XML, WSDL, Web Server layer etc will all takes its toll on performance.

While SOA offers several benefits, many SOA implementations are designed in a way that can impede performance.

2. Understand your Consumers (Throughput Vs Latency):

Keep consumers in mind right from day one, understand your target consumers.

When it comes to performance, it all boils down to two main things “throughput” and “latency”. Some consumers will be interested in getting quick response, some will be interested in the volume of messages you can process. They are two distinct terms and it will be hard to achieve both in a single environment. Often times you need to settle in-between at a level acceptable for the Business. The other approach is to maintain a pod based environment, where one pod is catered for low-latency and other pod is catered for high-throughput. If you got varying consumer profiles, be prepared to support them architecturally.

Low latency (quicker response in simple terms) is a relative term. It means different things to different systems. A latency figure of 5 seconds will be super good result for an online travel booking system querying 100’s of partners, but that’s awful result for an online trading system dealing with shares and stocks.

The service you write today for a low load application will be re-used tomorrow in a high load environment. The service you write today, which takes 40 seconds to respond will be ok for current consumers, but may not be appropriate for future consumers with low latency expectation (Example: Organisations web channel).

So, it’s better to understand your consumer requirements well in advance.

3. Poor performance may result in failed SOA initiative:

If you haven’t catered for these varying customer (profiles) requirements, it’s most likely your SOA initiative going to fail completely or partly.

Let me give you a classic example: From the above picture, imagine you are taking on board a new consumer, in this case WEB CHANNEL with very strict latency requirements (less than 2 seconds). They examine the coarse-grained business services and come to a conclusion; they are not capable of responding within 2 seconds. They then decided to make use of the fine-grained services directly. The WEB CHANNEL would have implemented the logic what’s in the “coarse-grained business services” again within their application (may be in a slightly different way).

It clearly kills the reusability and centralized business rules/logic repository.

Keep in mind, if your fine-grained services are also not good enough then they will go to the legacy assets (existing systems) directly, killing your whole SOA initiate.

4. Squeeze performance at every layer from bottom-up:

It’s more of a common sense; your higher level services performance will be directly proportional to the performance of the underlying services. You higher lever services latency cannot be reduced any lower than the slowest performing underlying service.

So, it’s vital you squeeze performance at every layer from bottom up. Any performance improvement you make on the bottom layer will help increase the performance of high level layers automatically.

Your performance test strategy should reflect this, plan well in advance.

Will BizTalk Server meet my low-latency SLA’s?

At least from my point of view, it’s clear from the above topics BizTalk server is NOT GOOD for building fine-grained services (bottom-layer) and it’s VERY GOOD for building composite business process (top-most layer). But when it comes to building coarse-grained middle layer, it’s always debatable whether BizTalk is a suitable product. The main reason will be the performance impact due to the usage of Message Box and wide misconception BizTalk doesn’t support low-latency scenarios very well.

To understand the consequence of the BizTalk architecture, let us experiment with couple of simple test cases to understand the overhead and also discuss the ways you can improve the performance.

Scenario #1: Single External call via Message Box

As shown in the below diagram, a BizTalk orchestration is developed calling an external fine-grained service via the Message Box. An orchestration is build purposely without taking messaging-only route, because in real world scenarios the coarse-grained services will invoke more than one fine-grained service, putting some business logic in-between. It’s feasible to do such scenarios only using orchestration.

Also the orchestration is exposed as a web service. Transformation is done on both directions.

The numbers shown in the diagram are from a real test, BizTalk polling interval was set to 100ms.

Key facts from above picture:

1. Latency of fine-grained service is 37 milliseconds
2. 271 milliseconds lost in the end-to-end transaction just on polling
3. Total latency (excluding web server overhead) is 500 milliseconds
4. There are 8 Message Box touch points in this simple scenario.

Scenario #2: Multiple External calls via Message Box

In this scenario, we modified the orchestration to make couple more external calls to the fine-grained services (same service/operation been used) via the Message Box as shown in the below figure.

Key facts from above picture:

1. Latency of fine-grained service are less than 50 milliseconds
2. 612 milliseconds lost in the end-to-end transaction just on polling
3. Total latency (excluding web server overhead) is 751 milliseconds
4. There are 16 Message Box touch points in this scenario.
5. End-To-End latency increases with more number of external calls.

Improving Scenario #1 – In-Line call from Orchestration

From the above 2 scenarios we can see considerable amount of time is spent on Message Box round-trips, it grows exponentially with more number of external calls we make. There are certain techniques we can adapt to reduce the number of Message Box hops as shown in the below figure:

In the above orchestration, the call to the external fine-grained service is done directly from the orchestration (a helper .NET component is used, which calls the external service.). You can notice it reduced the number of message box touch points from 8 to 4, and overall end-to-end latency from 500 to 188.

This design will result in losing some of the following functionality provided by BizTalk Server

1. Resilience:
2. Secondary transport
3. Secure/Easy end-point configuration
4. Service Window
5. Tracking
6. Switching Adapters

Basically we lost all of the abilities of the “Send Port” (NOTE: We only lost the capabilities of the send port not the send pipeline. Orchestration from BizTalk 2006 got the ability to execute the pipelines (both send/receive))

We need to analyse carefully and see how much of an impact it will be to lose these functionality to gain performance. In majority of the cases, you’ll be able to live with it or find some alternate ways for the ones important to you.

For example, out of the above loses

1. If “Resilience” is important to your solution, you could write some custom logic inside your orchestration to implement it.
2. If “Tracking” is important, then you can consider using custom BAM logging inside your orchestration
3. You may only need either SOAP or WCF custom implementation to communicate with your fine-grained services. Not the flexibility of all the 100+ adapters.
4. You can move the configuration from BizTalk binding files to .NET configuration files (See this link for securing it)

What do we gain by using BizTalk Server for coarse-grained services?

We have seen all the losses and alternate solution to the inline external call design. But there are lot of gains to be made due to the usage of BizTalk Server.

Following matrix gives you the list of things we gained by building our coarse-grained services using BizTalk Orchestrations. All these functionalities are part of BizTalk hosts, you need to ask yourself the question, whether you are in the business of building valuable business services for your organisation, or you are in the process of building proprietary host/containers for your business services.

Improving Scenario #2 – Multiple In-Line calls from Orchestration

The following diagram shows the solution to our second scenario using inline external calls. You can see the Message Box touch points reduced from 16 to just 4 and overall end-to-end latency reduced from 751 milliseconds to 221 milliseconds, a whooping ½ second gain per request.

Conclusion:

The alternate scenario discussed above is just one of the 1000+ things you can try in BizTalk to improve performance. There is various performance tuning measures you can follow (see performance optimisation guide) to improve your solution for better performance. Also, the important thing to note here is even though the scenario #1 and #2 looked complicated with various message box hops, still the response was send back within a second making 3 external calls.