SOA support in .NET

The .NET framework is the second of the two platforms for which we discuss SOA support in this book. As with the previous section, we first introduce the primary parts of the .NET platform and then delve into our familiar primitive SOA characteristics, service-orientation principles, and contemporary SOA characteristics. For each we explore .NET features that provide direct or indirect support.

We also need to repeat our disclaimer about how this chapter does not provide any detailed explanation of the .NET framework. A number of books exist dedicated to describing the various parts of the .NET development and runtime platform, and several are mentioned in the recommended reading page at www.serviceoriented.ws.

18.3.1. Platform overview

The .NET framework is a proprietary solution runtime and development platform designed for use with Windows operating systems and server products. The .NET platform can be used to deliver a variety of applications, ranging from desktop and mobile systems to distributed Web solutions and Web services.

A primary part of .NET relevant to SOA is the ASP.NET environment, used to deliver the Web Technology layer within SOA (and further supplemented by the Web Services Enhancements (WSE) extension).

Note

Version 2.0 of the .NET framework introduces some new features to and changes some aspects of the ASP.NET architecture. Where appropriate, these changes are pointed out in the sections that follow.

Figure 18.18 does not provide a model that represents the .NET framework in its entirety. Instead, it simply shows the typical layers upon which .NET service-oriented solutions are built. In this diagram the ASP.NET + WSE and Assemblies layers correspond to the Web and Component Technology layers in our original, vendor-neutral model we established at the beginning of this chapter. As shown in Figure 18.19, these and the other parts of the .NET framework inter-relate to provide a platform through which services can be created in support of SOA.

Figure 18.18. Relevant layers of the .NET framework, as they relate to SOA.

Figure 18.19. How parts of the .NET framework inter-relate.

 

Architecture components

The .NET framework provides an environment designed for the delivery of different types of distributed solutions. Listed here are the components most associated with Web-based .NET applications:

• ASP.NET Web Forms These are dynamically built Web pages that reside on the Web server and support the creation of interactive online forms through the use of a series of server-side controls responsible for auto-generating Web page content.
• ASP.NET Web Services An ASP.NET application designed as a service provider that also resides on the Web server.
• Assemblies An assembly is the standard unit of processing logic within the .NET environment. An assembly can contain multiple classes that further partition code using object-oriented principles. The application logic behind a .NET Web service is typically contained within an assembly (but does not need to be).

ASP.NET Web Forms can be used to build the presentation layer of a service-oriented solution, but it is the latter two components that are of immediate relevance to building Web services.

Runtime environments

The architecture components previously described rely on the Common Language Runtime (CLR) provided by the .NET framework. CLR supplies a collection of runtime agents that provide a number of services for managing .NET applications, including cross-language support, central data typing, and object lifecycle and memory management.

Various supplementary runtime layers can be added to the CLR. ASP.NET itself provides a set of runtime services that establish the HTTP Pipeline, an environment comprised of system service agents that include HTTP modules and HTTP handlers (see the Service agents section for more information). Also worth noting is that the established COM+ runtime provides a further set of services (including object pooling, transactions, queued components, and just-in-time activation) that are made available to .NET applications.

Programming languages

The .NET framework provides unified support for a set of programming languages, including Visual Basic, C++, and the more recent C#. The .NET versions of these languages have been designed in alignment with the CLR. This means that regardless of the .NET language used, programming code is converted into a standardized format known as the Microsoft Intermediate Language (MSIL). It is the MSIL code that eventually is executed within the CLR.

Note

Visual Studio establishes a standardized development environment through which .NET programming languages can be applied.

 

APIs

.NET provides programmatic access to numerous framework (operating system) level functions via the .NET Class Library, a large set of APIs organized into namespaces. Each namespace must be explicitly referenced for application programming logic to utilize its underlying features.

Following are examples of the primary namespaces that provide APIs relevant to Web services development:

• System.Xml Parsing and processing functions related to XML documents are provided by this collection of classes. Examples include:

  ~	The XmlReader and XmlWriter classes that provide functionality for retrieving and generating XML document content.
  ~	Fine-grained classes that represent specific parts of XML documents, such as the XmlNode, XmlElement, and XmlAttribute classes.

• System.Web.Services This library contains a family of classes that break down the various documents that comprise and support the Web service interface and interaction layer on the Web server into more granular classes. For example:

  ~	WSDL documents are represented by a series of classes that fall under the System.Web.Services.Description namespace.
  ~	Communication protocol-related functionality (including SOAP message documents) are expressed through a number of classes as part of the System.Web.Services.Protocols namespace.
  ~	The parent System.Web.Services class that establishes the root namespace also represents a set of classes that express the primary parts of ASP.NET Web service objects (most notably, the System.Web.Services.WebService class).
  ~	Also worth noting is the SoapHeader class provided by the System.Web. Services.Protocols namespace, which allows for the processing of standard SOAP header blocks.

In support of Web services and related XML document processing, a number of additional namespaces provide class families, including:

• System.Xml.Xsl Supplies documentation transformation functions via classes that expose XSLT-compliant features.
• System.Xml.Schema A set of classes that represent XML Schema Definition Language (XSD)-compliant features.
• System.Web.Services.Discovery Allows for the programmatic discovery of Web service metadata.

Note that we do not discuss these class libraries any further. They are only provided here to demonstrate the organization of .NET APIs into the .NET class hierarchy.

Service providers

.NET service providers are Web services that exist as a special variation of ASP.NET applications, called ASP.NET Web Services. You can recognize a URL pointing to an ASP.NET Web Service by the ".asmx" extension used to identify the part of the service that acts as the endpoint. ASP.NET Web Services can exist solely of an ASMX file containing inline code and special directives, but they are more commonly comprised of an ASMX endpoint and a compiled assembly separately housing the business logic.

Figure 18.20 shows how the pieces of a .NET Web service are positioned within our service provider model.

Figure 18.20. A typical .NET service provider.

 

Service requestors

To support the creation of service requestors, .NET provides a proxy class that resides alongside the service requestor's application logic and duplicates the service provider interface. This allows the service requestor to interact with the proxy class locally, while delegating all remote processing and message marshalling activities to the proxy logic.

The .NET proxy translates method calls into HTTP requests and subsequently converts the response messages issued by the service provider back into native method return calls.

The code behind a proxy class is auto-generated using Visual Studio or the WSDL.exe command line utility. Either option derives the class interface from the service provider WSDL definition and then compiles the proxy class into a DLL.

Figure 18.21 explains how .NET proxies behave within the standard service requestor model.

Figure 18.21. A typical .NET service requestor.

 

Service agents

The ASP.NET environment utilizes many system-level agents that perform various runtime processing tasks. As mentioned earlier, the ASP.NET runtime outfits the HTTP Pipeline with a series of HTTP Modules (Figure 18.22). These service agents are capable of performing system tasks such as authentication, authorization, and state management. Custom HTTP Modules also can be created to perform various processing tasks prior and subsequent to endpoint contact.

Figure 18.22. Types of .NET service agents.

Also worth noting are HTTP Handlers, which primarily are responsible for acting as runtime endpoints that provide request processing according to message type. As with HTTP Modules, HTTP Handlers can also be customized. (Other parts of the HTTP Pipeline not discussed here include the HTTP Context, HTTP Runtime, and HTTP Application components.)

Another example of service agents used to process SOAP headers are the filter agents provided by the WSE toolkit (officially called WSE filters). The feature set of the WSE is explained in the next section (Platform extensions), but let's first briefly discuss how these extensions exist as service agents.

WSE provides a number of extensions that perform runtime processing on SOAP headers. WSE therefore can be implemented through input and output filters that are responsible for reading and writing SOAP headers in conjunction with ASP.NET Web proxies and Web services. Much like the pre-processing scenarios we established in the Service agents sub-section of the SOA platforms section at the beginning of this chapter, WSE filters position themselves to intercept SOAP messages after submission on the service provider's end and prior to receipt on the service requestor's side.

Platform extensions

The Web Services Enhancements (WSE) is a toolkit that establishes an extension to the .NET framework providing a set of supplementary classes geared specifically to support key WS-* specification features. It is designed for use with Visual Studio and currently promotes support for the following WS-* specifications: WS-Addressing, WS-Policy, WS-Security (including WS-SecurityPolicy, WS-SecureConversation, WS-Trust), WS-Referral, and WS-Attachments and DIME (Direct Internet Message Encapsulation).

Note

We have not discussed WS-Referral or WS-Attachments in this book. The first is a Microsoft specification intended specifically to govern the use of SOAP routers. WS-Attachments uses the DIME encoding format used to send SOAP messages with attachments. For more information, see www.specifications.ws.

Case Study

Many of TLS's Web systems historically have been Java-based. In fact, the B2B solution explained throughout previous chapters was developed as a series of EJB Endpoints.

The original plan was for the upcoming Timesheet Submission project also to be delivered as part of the existing J2EE environment. However, the senior TLS architect in charge of overseeing the project was made aware of the recent availability of a team of four .NET consultants proficient in the delivery of ASP.NET Web Services.

This sparks the idea that this next solution could be based on the .NET framework instead. Subsequent to a meeting with management and peers, it is decided to hire these consultants to build the Timesheet Submission application as a .NET solution.

This decision is made for two reasons:

• TLS is curious to deliver an application based on the .NET framework and ASP.NET Web Services so that it can compare characteristics of the Timesheet Submission application (such as performance, stability, extensibility) with the existing J2EE B2B solution. In other words, TLS wants to use this opportunity to contrast vendor platforms.
• TLS made an effort to make all Web services part of the B2B solution fully WS-I Basic Profile-compliant. Though these services passed the criteria imposed on them by automated testing tools, TLS has not yet been able to prove real world compliance for those services that only perform internal tasks (public endpoint services, such as the Accounts Payable Service, are accessed by service requestors from different platforms every day and have therefore proven their cross-platform interoperability). By building ASP.NET Web Services in-house, TLS can test intrinsic interoperability characteristics for services from both solutions. Though not the primary reason for making this decision, this secondary benefit still is considered notable.

Given the freedom in vendor diversity provided by building service-oriented solutions, TLS can invest relatively safely in an application based on a different technology platform, knowing full well that .NET services should be fully interoperable with J2EE services (especially because TLS will be subjecting the .NET Web services to the same design standards used for their B2B solution).

Though it is technically safe, another consideration that factored into this decision was the maintenance commitment imposed by having to support both J2EE and .NET programming logic. Because TLS's IT environment is volatile and ever-growing, the risks and expenses associated with this consideration were deemed acceptable. The justification being that bringing a .NET solution within organizational boundaries will eventually lead to the development of in-house .NET expertise. It is hoped that this, in turn, will result in a more balanced skill-set that can accommodate the technology-related impact of future corporate mergers and acquisitions.

 

18.3.2. Primitive SOA support

The .NET framework natively supports primitive SOA characteristics through its runtime environment and development tools, as explained here.

Service encapsulation

Through the creation of independent assemblies and ASP.NET applications, the .NET framework supports the notion of partitioning application logic into atomic units. This promotes the componentization of solutions, which has been a milestone design quality of traditional distributed applications for some time. Through the introduction of Web services support, .NET assemblies can be composed and encapsulated through ASP.NET Web Services. Therefore, the creation of independent services via .NET supports the service encapsulation required by primitive SOA.

Loose coupling

The .NET environment allows components to publish a public interface that can be discovered and accessed by potential clients. When used in conjunction with a messaging framework, such as the one provided by Microsoft Messaging Queue (MSMQ), a loosely coupled relationship between application units can be achieved.

Further, the use of ASP.NET Web Services establishes service interfaces represented as WSDL descriptions, supported by a SOAP messaging framework. This provides the foremost option for achieving loose coupling in support of SOA.

Messaging

When the .NET framework first was introduced, it essentially overhauled Microsoft's previous distributed platform known as the Distributed Internet Architecture (DNA). As part of both the DNA and .NET platforms, the MSMQ extension (and associated APIs) supports a messaging framework that allows for the exchange of messages between components.

MSMQ messaging offers a proprietary alternative to the native SOAP messaging capabilities provided by the .NET framework. SOAP, however, is the primary messaging format used within contemporary .NET SOAs, as much of the ASP.NET environment and supporting .NET class libraries are centered around SOAP message communication and processing.

18.3.3. Support for service-orientation principles

The four principles we identified in Chapter 8 as being those not automatically provided by first-generation Web services technologies are the focus of this section, as we briefly highlight relevant parts of the .NET framework that directly or indirectly provide support for their fulfillment.

Autonomy

The .NET framework supports the creation of autonomous services to whatever extent the underlying logic permits it. When Web services are required to encapsulate application logic already residing in existing legacy COM components or assemblies designed as part of a traditional distributed solution, acquiring explicit functional boundaries and self-containment may be difficult.

However, building autonomous ASP.NET Web Services is achieved more easily when creating a new service-oriented solution, as the supporting application logic can be designed to support autonomy requirements. Further, self-contained ASP.NET Web Services that do not share processing logic with other assemblies are naturally autonomous, as they are in complete control of their logic and immediate runtime environments.

Reusability

As with autonomy, reusability is a characteristic that is easier to achieve when designing the Web service application logic from the ground up. Encapsulating legacy logic or even exposing entire applications through a service interface can facilitate reuse to whatever extent the underlying logic permits it. Therefore, reuse can be built more easily into ASP.NET Web Services and any supporting assemblies when developing services as part of newer solutions.

Statelessness

ASP.NET Web Services are stateless by default, but it is possible to create stateful variations. By setting an attribute on the service operation (referred to as the WebMethod) called EnableSession, the ASP.NET worker process creates an HttpSessionState object when that operation is invoked. State management therefore is permitted, and it is up to the service designer to use the session object only when necessary so that statelessness is continually emphasized.

Discoverability

Making services more discoverable is achieved through proper service endpoint design. Because WSDL definitions can be customized and used as the starting point of an ASP.NET Web Service, discoverability can be addressed, as follows:

• The programmatic discovery of service descriptions and XSD schemas is supported through the classes that reside in the System.Web.Services.Discovery namespace. The .NET framework also provides a separate UDDI SDK.
• .NET allows for a separate metadata pointer file to be published alongside Web services, based on the proprietary DISCO file format. This approach to discovery is further supported via the Disco.exe command line tool, typically used for locating and discovering services within a server environment.
• A UDDI Services extension is offered on newer releases of the Windows Server product, allowing for the creation of private registries.
• Also worth noting is that Visual Studio contains built-in UDDI support used primarily when adding services to development projects.

18.3.4. Contemporary SOA support

Keeping in mind that one of the contemporary SOA characteristics we identified early on in Chapter 3 was that SOA is still evolving, a number of the following characteristics are addressed by current and maturing .NET framework features and .NET technologies.

Based on open standards

The .NET Class Library that comprises a great deal of the .NET framework provides a number of namespaces containing collections of classes that support industry standard, first-generation Web services specifications.

As mentioned earlier, the WSE extension to .NET provides additional support for a distinct set of WS-* specifications. Finally, as described later in the Intrinsically interoperable section, version 2.0 of the .NET framework and Visual Studio 2005 provide native support for the WS-I Basic Profile.

Also worth noting is that Microsoft itself has provided significant contributions to the development of several key open Web services specifications.

Supports vendor diversity

Because ASP.NET Web Services are created to conform to industry standards, their use supports vendor diversity on an enterprise level. Other non-.NET SOAs can be built around a .NET SOA, and interoperability will still be a reality as long as all exposed Web services comply to common standards (as dictated by the Basic Profile, for example).

The .NET framework provides limited vendor diversity with regard to its development or implementation. This is because it is a proprietary technology that belongs to a single vendor (Microsoft). However, a third-party marketplace exists, providing numerous add-on products. Additionally, several server product vendors support the deployment and hosting of .NET Web Services and assemblies.

Intrinsically interoperable

Version 2.0 of the .NET framework, along with Visual Studio 2005, provides native support for the WS-I Basic Profile. This means that Web services developed using Visual Studio 2005 are Basic Profile compliant by default. (Previous versions of Visual Studio can be used to develop Basic Profile compliant Web services, but they require the use of third-party testing tools to ensure compliance.) Additional design efforts to increase generic interoperability also can be implemented using standard .NET first-generation Web services features.

Promotes federation

Although technically not part of the .NET framework, the BizTalk server platform can be considered an extension used to achieve a level of federation across disparate enterprise environments. It supplies a series of native adapters and is further supplemented by a third-party adapter marketplace. BizTalk also provides an orchestration engine with import and export support for BPEL process definitions.

Architecturally composable

The .NET Class Library is an example of a composable programming model, as classes provided are functionally granular. Therefore, only those functions actually required by a Web service are imported by and used within its underlying business logic.

With regard to providing support for composable Web specifications, the WSE supplies its own associated class library, allowing only those parts required of the WSE (and corresponding WS-* specifications) to be pulled into service-oriented solutions.

Extensibility

ASP.NET Web Services subjected to design standards and related best practices will benefit from providing extensible service interfaces and extensible application logic (implemented via assemblies with service-oriented class designs). Therefore, extensibility is not a direct feature of the .NET framework, but more a common sense design approach to utilizing .NET technology.

Functional extensibility also can be achieved by extending .NET SOAs through compliant platform products, such as the aforementioned BizTalk server.

Supports service-oriented business modeling

Service-oriented business modeling concepts can be implemented with .NET by creating the standard application, entity-centric, and task-centric service layers described earlier in this book.

The orchestration layer requires the use of an orchestration engine, capable of executing the process definition that centralizes business workflow logic. Orchestration features are not a native part of the .NET framework. However, they can be implemented by extending a .NET solution environment with the BizTalk server platform.

Logic-level abstraction

.NET SOAs can position ASP.NET Web Services and service layers to abstract logic on different levels. Legacy and net-new application logic can be encapsulated and wholly abstracted through proper service interface design. Service compositions can be built to an extent through the use of custom SOAP headers and correlation identifiers or by taking advantage of WSE extensions, such as the support provided for WS-Addressing and WS-Referral. (WSE also provides fundamental support for message-level security through extensions that implement portions of the WS-Security framework.)

Organizational agility and enterprise-wide loose coupling

Because the .NET framework supports the development of industry-standard Web services, the proper positioning and application of service layers allows for the creation of the required layers of abstraction that promote fundamental agility. The use of an orchestration layer can further increase corporate responsiveness by alleviating services from business process-specific logic and reducing the need for task-centric services.

The ultimate state of a service-oriented enterprise is to attain a level of bi-directional agility between business and technology domains. This can be achieved through contemporary SOA and requires that many of the discussed characteristics be fully realized. The .NET framework provides a foundation for SOA, capable of fully manifesting the primitive SOA characteristics and select qualities associated with contemporary SOA. Microsoft extensions to the .NET framework and third-party products are required to implement enterprise-wide loose coupling and realize the benefits associated with organizational agility.

SUMMARY OF KEY POINTS

• Building service-oriented solutions with .NET typically involves creating service providers as ASP.NET Web Services (supported by processing logic in business components implemented as assemblies) and service requestors that use auto-generated proxy classes.
• The Common Language Runtime and the .NET Class Library are cornerstones of the .NET framework.
• .NET provides the necessary environment and tools to build primitive SOAs.
• The four outstanding principles of service-orientation can be realized by applying design conventions to ASP.NET Web Services. Principles such as autonomy and reusability are achieved more easily when adding new service logic (as opposed to encapsulating legacy logic), whereas discovery requires explicit design.
• A subset of the contemporary SOA characteristics can be fulfilled with native .NET features, while others can be realized through product extensions.
• The .NET framework provides industry-compliant support for Web services and the WS-I Basic Profile. Further, it supports the limited implementation of select WS-* specifications, via the WSE toolkit.