[Bernstein09] 10.3. .NET Framework

10.3. .NET Framework

• Windows Presentation Foundation (WPF), ASP.NET, and Silverlight for developing PC-based or browser-based front-end programs.

• Windows Communication Foundation (WCF) and the Internet Information Server (IIS) for developing and deploying request controllers and transaction servers.

• Host Integration Server (HIS) and BizTalk Server adapters for integration with legacy environments. In some instances of the multitier architecture, the transaction server and/or resource manager can be hosted within a legacy environment. Interoperability tools such as these can include them into the .NET Framework environment.

• Windows Workflow Foundation (WF) and WS-BPEL support in BizTalk Server for creating and executing business processes, including those that combine multiple services.

Except for HIS and BizTalk Server, these components are bundled into Windows operating systems, starting with the Vista release. Most components are also available as downloads for prior versions of Windows.

Figure 10.4 shows that a front-end program can be written to run in a web browser and connect to a web server acting as a request controller. Or it can connect directly to the database acting as a web server (not shown) or transaction server.

Figure 10.4. .NET Framework Multitier Transactional Middleware Architecture. The components of the .NET Framework multitier architecture provide multiple options for developing and deploying front-end programs, request controllers, and transaction servers.

A native PC program created using WPF can also connect to a web server. Or it can communicate directly with either a request controller or a transaction server. Similarly, a Web Services client can communicate directly with an application process or the database (not shown in the figure).

A request controller can be developed to run in a web server or as an application process using WCF. A transaction server can be implemented to run as an application process using WCF or as a stored procedure in a database system.

An application developed using the .NET Framework transactional middleware components can therefore implement a two-tier, three-tier, or multitier architecture to meet scalability, availability, and other TP application requirements.

Any server-side component or combination of components can use the transaction management capabilities of the platform through either the implicit or explicit programming models, either with or without using WCF.

A variety of deployment functions also are supported to meet TP application requirements for scalability, availability, and reliability. These include Windows operating system services, IIS application spaces, and Windows Server clusters.

A WCF program can use Web Services standards to interoperate with a legacy TP monitor or Java-based product, such as a Java-EE-compliant application server.

Developing Front-End Programs

In the .NET Framework the technologies used for front-end programs include:

• Windows Presentation Foundation for PC- or browser-based GUIs

• ASP.NET and Silverlight for web browser-based GUIs

The Windows Presentation Foundation (WPF) provides a comprehensive environment for developing front-end programs that implement menus and forms with high levels of interactivity, control, and graphical capability. WPF is intended to consolidate and replace prior generations of Windows-based graphical user interface (GUI) frameworks. WPF also can be used to create a GUI that runs in a web browser.

ASP.NET provides a complete development and deployment environment for web-based applications. A second option, Silverlight, provides a subset of WPF and .NET for cross-platform use; that is, for multiple operating systems and web browsers.

Windows Presentation Foundation

WPF uses XAML (Extensible Application Markup Language, pronounced “zammel”), which is an XML syntax for initializing structured values. In WPF, these structured values define components of a GUI. WPF commands are expressed using XAML, or alternatively using a CLR-based programming language such as C# or Visual Basic (VB).

Front-end programs developed using XAML commands can be deployed in a browser or in a native PC environment, which Microsoft calls a standalone application. A standalone application can be hosted in its own window or in a special window provided by WPF that offers basic navigation features. WPF can directly access data in a database or other resource. The .NET Framework provides several options for this, including ADO.NET, LINQ (Language-Integrated Query), and various mechanisms to execute a stored procedure in SQL Server (see Section 10.5 for further information). WPF also can be used in combination with WCF to connect to request controllers and transaction servers in a multitier architecture.

A complete front-end program requires a combination of a XAML markup file to define the display characteristics, a CLR-based program for the execution logic, and a configuration file to bind the display characteristics to the program. The configuration file generates an executable file for deployment in the target hosting environment (Visual Studio, standalone, or web browser).

Figure 10.5 illustrates a simple front-end program snippet defined using WPF. XAML commands exist within the XAML namespace. The XAML commands are contained within a top-level structure called a page, which is similar to an operating system window or a web page. The top-level page is called a home page, which in the example is the Transfer page. A single front-end program can have multiple pages corresponding to multiple display panels for additional menus and forms.

Figure 10.5. Simple XAML Commands for WPF. These sample XAML commands define a form title and the form’s position on the screen.

<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" x:Class="Transfer.HomePage" WindowTitle="Transfer Funds" Title="Transfer - Home" WindowWidth="550" WindowHeight="380"> </Page>

The display panel defined by the home page in the example is given the title “Transfer Funds.” The Transfer class is set as the namespace for all subpages and programs associated with this display. The display width and height are specified in pixels. Additional controls typically are added to define fields and buttons and to map data into and out of the page. For example, input fields could be added in C# to capture the user’s bank account numbers and transfer amount for an update operation.

The C# snippet in Figure 10.6 illustrates a program associated with the Transfer home page. Additional C# logic typically is added to handle GUI events, such as what steps to perform on a button click or pressing Enter. In WPF terminology this is called a code behind file to handle events defined in the XAML file. The code behind file is merged with the code generated by processing the XAML definitions. For example, the XAML steps would obtain from the user the account number and amount to transfer between bank accounts and the C# code would execute the actual transfer operation. A build step combines any XAML files and associated C# files into an executable that can be run from a command line or within Visual Studio for testing and debugging.

Figure 10.6. Sample C# Class Associated with a WPF Page. The C# code is merged with code generated from the corresponding XAML file, for example to implement a button object that submits form input data.

using System; using System.Windows; using System.Windows.Controls; using System.Windows.Navigation; namespace Transfer { public partial class HomePage : Page { public HomePage() { InitializeComponent(); void Button(object sender, FormInput e) } } }

The .NET Framework environment supports the use of multiple approaches for front-end program construction. In particular, a front-end program developed independently of .NET can use standard HTTP, the REST/HTTP protocol, or another Web Service invocation mechanism compatible with WCF to invoke a .NET Framework request controller or transaction server.

ASP.NET and Silverlight

ASP.NET supports the development and deployment of web-based applications, including components to create a GUI for a web browser and a hosting environment in the IIS web server for processing requests. ASP.NET applications can be developed using any CLR-based language and can use any of the classes in the .NET Framework, including capabilities for security, transactions, and system administration. ASP.NET also supports Web Services development and deployment.

Silverlight is used similarly to WPF to develop front-end programs that can be used natively on Windows or with any web browser. Silverlight programs can be included within static HTML files and server-generated pages (e.g., using PHP, Python, or Ruby scripts). Like WPF, Silverlight programs include XAML files and code in the form of class files that are associated with the XAML files.

Silverlight supports a JavaScript/AJAX programming model and a cross-platform, cross-browser version of the .NET Framework. This allows developers of front-end programs to write Silverlight applications using any .NET language (including VB, C#, JavaScript, IronPython, and IronRuby) and deploy it on a range of operating systems and web browsers. Silverlight supports REST, Web Services, XML over HTTP, RDF Site Summary (RSS), and standard HTTP communication protocols for interaction with web servers and WCF services.

Developing Request Controllers and Transaction Servers

WCF provides a set of capabilities that can be used to connect a front-end program to a request controller or transaction server developed using the .NET Framework. WCF implements a service-oriented interaction model that can be configured for CLR objects created using Visual Basic .NET and C#. Many of the WCF libraries are also available to programs created using C++, J#, and JScript. WCF supports both implicit and explicit transaction programming models and works with all Microsoft SQL Server versions and ADO.NET compliant resource managers. WCF also includes .NET libraries that work with COM and COM+ components.

For communications WCF supports a variety of configurable messaging models and data formats, including native remote procedure call (RPC), Web Services, and asynchronous queuing (using Microsoft Message Queuing). WCF also supports custom-developed protocols and formats.

A WCF service requires an explicit contract, which is an interface to a .NET Framework object. The interface must be associated with an executable class file that contains the program logic. It must also be associated with a binding that specifies the data format, communication protocol, and additional characteristics of the communication session (such as reliability, security, or transaction propagation) for the operations in the interface.

A WCF interface describes a service that can be invoked remotely and defines any additional distributed computing characteristics for each method. For example, the interface shown in Figure 10.7 is called ITransfer and includes four methods: AccountBalance, WithdrawAccount, DepositAccount, and Transfer. The interface is marked as a service using [ServiceContract], and each method in the service is marked as being remotely accessible using [OperationContract]. Not all methods have to be made available remotely, but when they are they must be tagged with the [OperationContract] attribute.

Figure 10.7. WCF Interface Definition. An interface that exposes a service remotely is a core feature of WCF. Multiple bindings can be configured for an interface, including Web Services and native.

[ServiceContract] Interface ITransfer { [OperationContract] void AccountBalance (decimal AccountNumber, decimal); [OperationContract] void WithdrawAccount (decimal AccountNumber, decimal Amount); [OperationContract] void DepositAccount (decimal AccountNumber, decimal Amount); [OperationContract] void Transfer(decimal FromAccountNumber, decimal ToAccountNumber, decimal Amount); }

Transactions

Three main attributes affect the transaction behavior of a method:

• TransactionFlowOption is specified on the interface to the method and tells whether the method will accept a transaction context propagated from its caller.

• TransactionScopeRequired property of the OperationBehavior attribute is specified on an implementation of the method and tells whether the method must execute within a transaction.

• TransactionFlow is specified on the binding that the caller uses to invoke the method and tells whether the caller’s transaction context can flow across the binding.

The [TransactionFlow] attribute on an interface has three possible values: Mandatory, Allowed, and NotAllowed. The Mandatory attribute shown in Figure 10.8 indicates that the WithdrawAccount operation must receive a transaction context when invoked by another method. Allowed means that the service accepts a transaction context if one is received with the message, but it does not require the message to contain one. NotAllowed is the default and means that the service ignores a propagated transaction context.

Figure 10.8. Using the TransactionFlow Attribute to Require Propagation. Adding attributes to the WCF interface controls transaction propagation.

[OperationContract] [TransactionFlow(TransactionFlowOption.Mandatory)] void WithdrawAccount(int AccountNumber,int Amount);

An annotated class implements a WCF interface definition. The class defines the execution logic for each of the methods listed in the service, such as methods that access a database, do computation, or invoke other services. The TransactionScopeRequired attribute on each method is set to true or false, indicating whether or not the operation must be executed within a transaction. For example, in Figure 10.9 the WithdrawAccount and DepositAccount methods have a TransactionScopeRequired attribute of true, so they must always execute in the context of a transaction.

Figure 10.9. Defining the Object Class for the Interface. Each operation in a WCF interface has a method in a corresponding object class for its implementation.

class TransferService : Transfer { [OperationBehavior(TransactionScopeRequired = true)] public void WithdrawAccount (int accountNumber, decimal amount) } { [OperationBehavior(TransactionScopeRequired = true)] public void DepositAccount (int accountNumber, decimal amount) ... }

Suppose the binding between the caller and the service indicates that the caller’s transaction context can flow across the binding (details are in the next section). The combination of values for TransactionFlowOption and TransactionScopeRequired lead to a variety of possible behaviors. For example:

• If the caller is executing a transaction, the TransactionFlowOption on the method is Mandatory or Allowed, and TransactionScopeRequired is true, then the method executes in the caller’s transaction.

• If the caller is executing a transaction, the TransactionFlowOption is NotAllowed, and TransactionScopeRequired is true, then the method executes in a new transaction.

• If the caller is not executing a transaction and TransactionScopeRequired is true, then the method executes in a new transaction, no matter what value is specified for TransactionFlowOption.

Transaction termination depends on the successful completion of each method executed within the transaction. That is, a transactional object is considered a participant in the transaction and must provide a completion vote for the transaction to commit. If the TransactionAutoComplete attribute is true (which is the default), then the transaction is completed automatically if it exits without throwing an unhandled exception. Such an exception means the transactional object will vote to abort.

A one-way flow (i.e., a one-way asynchronous message exchange) is not allowed to propagate a transaction context, although a correlated request/reply message exchange using an asynchronous communication protocol is allowed to propagate a context.

So far nothing has indicated which wire format is used. The type of transaction context is specified in the WCF binding.

Bindings

Internally, WCF is based on the chain of responsibility architecture, in which a series of handlers (sometimes called interceptors) are inserted into the call chain between client and server, including a handler that propagates transaction context for a remote service. The chain of responsibility pattern can be implemented as an extension to the RPC mechanism. When the proxies and stubs are generated from the interface, the code for the handlers is inserted into the call chain to implement any additional characteristics associated with the interface defined using configuration metadata. Handlers are inserted into the call chain in a predetermined order, according to the type of functionality they provide. For example, a message serialization handler must execute before a handler that dispatches the serialized message onto the communications protocol.

The call chain handlers in WCF are called channels and are visible to developers in collections called bindings. A binding is basically a collection of related channels designed to fulfill a specific task, such as transmit a Web Services request using HTTP. A binding contains an ordered collection of binding elements, such as the TransactionFlowBindingElement in a transaction propagation channel. The various communication and transaction propagation capabilities offered by WCF therefore are expressed in the collection of available channels. Custom bindings can also be defined. A local optimization of a WCF binding is used when services are deployed into the same address space.

An extended HTTP binding, WSHttpBinding, shown in Figure 10.10, is used for messages that need binding elements for SOAP headers defined in extended Web Services specifications such as WS-Security for message-based security, WS-ReliableMessaging for reliable message exchange, and WS-AtomicTransaction for transaction context propagation. A simpler HTTP binding, BasicHttpBinding, which is aimed at WS-I Basic Profile conformance, is used to transmit a basic SOAP-formatted message over HTTP. In the simpler binding, HTTP security is used for basic encryption, authentication, and authorization, and transactions are not supported.

Figure 10.10. WCF Bindings Consist of a Collection of Channels. The WSHttpBinding combines channels for Web Service transaction context propagation, message formatting, and transport.

[View full size image]

The example in Figure 10.11 illustrates a configuration for the Transfer service. The executable service logic, interface contract, and communications binding are combined in an endpoint definition. The endpoint identifies the executable file for the service as TransferService.svc and gives its network address as a URL. The service uses the WSHttpBinding for the interface contract ITransfer, and a TransactionalHTTP binding configuration, which will propagate the transaction context using WS-AtomicTransaction.

Figure 10.11. Endpoint Definition for a WCF Service. The endpoint definition maps an interface to one or more bindings, such as WSHttpBinding for transactional Web Services.

<endpoint address = "http://localhost:8002/TransferService.svc" bindingConfiguration = "TransactionalHTTP" binding = "wsHttpBinding" contract = "ITransfer"/>

WCF also offers a binding, called NetTcpBinding, for directly sending a binary message over TCP/IP. The message format is optimized for internal communications and available for use only among WCF services. The NetTcpBinding supports transaction propagation and a configurable selection of formats for the transaction context. The format choices include OLE Transactions, WS-AtomicTransaction 2004, or WS-AtomicTransaction 1.1.

A WCF service can be configured to support multiple bindings and thus multiple communication protocols and data formats. For example, a developer may want to publish a service over NetTcpBinding for optimized WCF-WCF communications and over WSHttpBinding to allow access from external Web Services clients. This simply requires specifying multiple bindings for the service in its associated endpoint configuration file. To propagate transaction context, however, it’s always necessary to choose a transactional binding; that is, one that can include a TransactionFlowBindingElement.

The code in Figure 10.12 illustrates a WCF service endpoint that uses two bindings, TransactionalTCP and TransactionalHTTP. This makes TransferService available over each protocol on a different port number (8001 and 8002, respectively). In the binding definitions for NetTCPBinding and WsHttpBinding, the transactionFlow attribute is set to true (the default is false). In this case both bindings are transaction-aware and the flow attribute requires transaction context to propagate. In other words, the TransferService is configured to accept a transactional service invocation over both TCP and HTTP. The TCP channel will receive OLE-Transactions context and the HTTP channel will receive WS-Transaction’s WS-AT context.

Figure 10.12. Configuration File Example for WCF Services. Transactional bindings for both binary and HTTP-based protocols can be configured for the same service, using different port numbers.

Code View: Scroll / Show All <?xml version = "1.0" encoding = "utf-8" ?> <configuration> <system.serviceModel> <services> <service name = "TransferService"> <endpoint address = "net.tcp://localhost:8001/TransferService/" bindingConfiguration = "TransactionalTCP" binding = "netTcpBinding" contract = "ITransfer" /> <endpoint address = "http://localhost:8002/TransferService/" bindingConfiguration = "TransactionalHTTP" binding = "wsHttpBinding" contract = "ITransfer" /> </service> <bindings> <NetTcpBinding> <binding name = "TransactionalTCP" transactionFlow = "true" /> </NetTcpBinding> <WsHttpBinding> <binding name = "TransactionalHTTP" transactionFlow = "true" /> </WsHttpBinding> </bindings> </system.serviceModel> </configuration>

Discussion

The implicit programming model was first implemented in .NET as a single attribute associated with an interface that applied to all methods of the interface. The attribute defined both how the method would handle a transaction context when invoked, and whether or not the method would create a new transaction if it did not receive a context on the invocation. That is, a single setting controlled whether or not a method would accept a transaction context propagation and whether or not the called method would create a new transaction if it didn’t receive one. This is still the model use in Java EE.

This changed in WCF. First, attributes are associated with individual methods, not the entire interface. Second, WCF uses separate attributes to demarcate a transaction and to control the propagation of transaction context. This allows a potential separation of roles between a developer and system integrator. A developer wants to require that his method executes in a transaction because it accesses transactional resources. But he wants to allow the method to be called by another method that is already operating inside a transaction. He does not necessarily want to define an exception handler, because the exception handler’s behavior may be different depending on whether the transaction is demarcated by his method or a method that invokes his method.

Consider a system integrator who is reusing an existing transactional method M in a larger application. He or she may need to control whether M executes in the context of the caller’s transaction. For example, if M logs a security violation, it needs to run as a transaction, which the developer of M can specify. The system integrator needs to control whether or not the security violation will be logged even if the caller’s transaction aborts. He or she can do this by deciding whether or not the caller’s transaction context is propagated to M. If so, then M will run in the caller’s transaction. If not, then M will run as a top-level transaction and commit independently of the caller. The system integrator can configure two different callers so that one propagates transaction context and the other doesn’t.

In the earlier model, the decisions of transaction demarcation and context propagation were linked. That is, a single attribute controlled whether M executes as a transaction and whether it executes in the context of the caller’s transaction. In WCF, these decisions are made separately.

REST/HTTP Support

REST/HTTP support in NET is provided using enhancements to WCF, including templates for constructing and using URLs with HTTP verbs, and attributes for defining REST-based operations in a WCF interface. WCF provides a nontransactional binding for REST/HTTP style services called WebHttpBinding.

WCF Deployment Options

WCF supports several hosting options, including IIS running on Windows Server clusters for scalability and availability. For production, one option is to use a Windows hosted “service” (not to be confused with a WCF service). WCF programs can also be hosted using IIS worker processes. Or they can be included in ASP.NET applications.

Initially, the IIS hosting environment was available only for HTTP-based communications. As of the Windows Vista release, the application hosting environment portion of IIS is packaged separately, so it can now accept incoming requests over any communication protocol that WCF supports.

In a Windows Server cluster environment, it’s possible to configure the transaction manager to manage transactions centrally or per machine. When configured per machine, if one machine fails, then a transaction manager on another machine can assume responsibility for coordinating transactions for the failed machine’s transaction manager. A clustered transactional application must use a cluster-aware transaction manager to ensure correct results and meet availability requirements. In general, performance is improved by colocating the transaction manager in a cluster with the resource manager(s) being coordinated.

Transaction Management Using System.Transactions

The runtime infrastructure for creating transactional services and objects in the .NET Framework is delivered in the System.Transactions API. The API supports both implicit and explicit transaction programming models, either for .NET programs running on their own or for those defined within WCF. The .NET transaction management infrastructure uses a context called an ambient transaction, which is created for any Windows operating system thread that runs transactional code. If an ambient transaction already exists when an object needs a transaction context, then the existing ambient transaction is used. If not, then a new one is created.

Two transaction managers are used in .NET. The general-purpose transaction manager for transactions that use multiple resource managers (RMs) is the Microsoft Distributed Transaction Coordinator (DTC). There is also the Lightweight Transaction Manager (LTM), which can handle any number of volatile resources and at most one persistent resource. LTM is cheaper than DTC because it doesn’t require a log.

To minimize transaction overhead, System.Transactions optimizes transaction coordination by attempting to use the LTM when possible. A transaction starts out being managed by LTM. If the transaction only accesses volatile resources, then LTM coordinates the transaction. If the transaction accesses a persistent resource, such as SQL Server or the transactional NT File System (TxF), then an optimization strategy called Promotable Single Phase Enlistment (PSPE) comes into play. It transparently promotes the lightweight in-memory transaction to a persistent single-phase transaction. To coordinate the transaction, LTM commits the volatile resources and then transfers commit coordination responsibility to the durable RM. If the transaction accesses a second durable RM, propagates the transaction to another process, or takes other actions that are beyond LTM’s ability to manage, then LTM delegates the transaction coordination to DTC.

SQL Server version 2005 and higher are compatible with PSPE and can therefore handle the delegation or promotion of control when a transaction is started by System.Transactions. DTC supports any XA-compliant RM, such as Oracle Database and IBM’s DB2, and can include them within a DTC managed transaction.

The Explicit Programming Model

The explicit model in System.Transactions incorporates transaction management APIs directly into application code. Developers use the methods in the Transaction class to manage transactional behavior. Similar to the implicit programming model, the explicit programming model can be used in any .NET programming language, within or outside of WCF.

A typical approach to manage transactions explicitly is to set a transaction scope on a using or try block. All operations on data within the block execute within the scope of the transaction. This includes any methods called from within the block, unless explicitly excluded.

An example is shown in Figure 10.13. The TransactionScope() object is instantiated within a using block, and the AccountDeposit operation within the block is contained within the transaction. Instantiating a TransactionScope() object starts a new transaction or joins an ambient transaction, if one exists. The default TransactionScopeOption is Required. In the explicit model, the transaction is completed using the complete method instead of using the Autocomplete attribute. However, the result is the same—the transaction is committed if all participants vote complete and the execution of all methods is successful (i.e., no unhandled exceptions are thrown).

Figure 10.13. Explicit Transaction Management Using TransactionScope(). The TransactionScope() class code snippet shown picks up an existing ambient transaction or initiates a new transaction and votes to successfully complete the transaction if no exception is thrown.

using (TransactionScope tx = new TransactionScope()) { //... AccountCredit = 100.00M; AccountID = 77392; AccountDeposit(AccountID, AccountCredit); //... tx.Complete(); }

The System.Transactions explicit model API also can be used to bracket multiple SQL connections. In Figure 10.14 a new transaction scope is created explicitly. The first using block creates an initial SQL connection that executes an insert command. A second using block creates a second SQL connection that executes an update command. After both SQL commands complete successfully, the scope.complete() operation indicates the work of this method is done, and the method is prepared for the transaction to be committed. For simplicity, exception handling logic that typically is added to the using blocks has been omitted.

Figure 10.14. Bracketing Multiple SQL Connections. In this example, nested using blocks are defined to connect to two SQL databases and coordinate a transaction across both.

Code View: Scroll / Show All using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection connection = new SqlConnection(connectionString)) { SqlCommand command = connection.CreateCommand(); command.CommandText = "Insert...."; connection.Open(); command.ExecuteNonQuery(); connection.Close(); using (SqlConnection connection2 = new SqlConnection (connectionString) { SqlCommand command2 = connection2.CreateCommand(); command2.CommandText = "Update...."; connection.Open(); command2.ExecuteNonQuery(); } } scope.Complete(); }

The TransactionScopeOption choices are:

• Required: Join the existing ambient transaction, or create a new one if one does not exist.

• RequiresNew: Create a new transaction whether or not an ambient transaction was present.

• Suppress: Execute outside the scope of a transaction, that is, suppress the ambient transaction.

A transaction context is associated with a scope object created when a transaction is initiated. The decision to create a new transaction depends on the TransactionScopeOption attribute defined for the object.

The explicit programming model offered by System.Transactions allows a developer to control transaction bracketing without decomposing transactions into separate methods. It also offers more control over the details of transaction management, such as getting and manipulating the transaction context and logging transaction IDs. For example, a program can obtain a reference to the ambient transaction context as follows:

Transaction ambientTransaction = Transaction.Current;

This enables a program to pass its ambient transaction to another party. The ambient transaction can be changed by setting Transaction.Current, which enables a program to control its transaction context explicitly.

Integration with Legacy TP Monitors

The .NET Framework includes the Microsoft Host Integration Server to access CICS and IMS transactions and DB2 databases. BizTalk Server Adapters for Host Systems can be used to integrate with other existing systems and legacy TP monitors. The Line of Business adapter toolkit in WCF and BizTalk Server can be used to develop a custom adapter where no packaged adapter exists.

Transactional integration with existing systems and legacy TP monitors is offered specifically for CICS and IMS using a two-phase commit bridge between DTC and mainframe transaction managers using the LU6.2 protocol in the Host Integration Server product. Transactional integration also is offered generically via Web Services transactions in WCF and XA support in DTC, both of which can also be used with BizTalk Server. Existing systems also can be wrapped using Web Services and accessed via WCF, either standalone or together with BizTalk Server.

Host Integration Server offers a direct connection to DB2 databases from the .NET Framework. Programs that access mainframe transactions from the .NET Framework can be developed using Visual Studio, including the ability to import metadata from legacy environments in the form of COBOL Copy Books and RPG data definitions. A data access tool provides a mapping to the DB2 data sources. It’s also possible to manage database connections to mainframe databases from the .NET Framework environment and integrate them with connections to SQL Server data sources.

Host Integration Server also supports an option for using IBM 3270 terminal communications protocol over TCP/IP.