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).
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.
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 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.
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.
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.
Visual Studio establishes a standardized development environment through which .NET programming languages can be applied.
.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:
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.
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:
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.
.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.
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.
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.
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).
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.
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:
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
.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
Part I: SOA and Web Services Fundamentals
The Evolution of SOA
Web Services and Primitive SOA
Part II: SOA and WS-* Extensions
Web Services and Contemporary SOA (Part I: Activity Management and Composition)
Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)
Part III: SOA and Service-Orientation
Principles of Service-Orientation
Part IV: Building SOA (Planning and Analysis)
SOA Delivery Strategies
Service-Oriented Analysis (Part I: Introduction)
Service-Oriented Analysis (Part II: Service Modeling)
Part V: Building SOA (Technology and Design)
Service-Oriented Design (Part I: Introduction)
Service-Oriented Design (Part II: SOA Composition Guidelines)
Service-Oriented Design (Part III: Service Design)
Service-Oriented Design (Part IV: Business Process Design)
Fundamental WS-* Extensions
Appendix A. Case Studies: Conclusion