Defining the Solutions Architecture

Traditional application architecture is distributed across machine and operating system boundaries to improve performance, scalability, and availability. This application design pattern often leads to applications and systems becoming islands of data, each with their own geographic and physical boundaries. Developers are then forced to duplicate concepts and functionalities across systems as a way of compensating for these borders. Also, traditional system architecture didn t account for integration during its design. As a result additional restrictions and layers that made applications difficult to maintain and, especially , change were created. Tightly coupled systems led to hard connected application layers that often increased the complexity of integration.

The adoption of Web Services and XML has caused a shift in the way applications are designed. Today we want to design applications as a collection of interacting services. Each service provides access to a well-defined collection of unique functionality. Exposing functionality as a service gives additional flexibility to applications that allows them to make use of other services in a natural way regardless of their physical location.

A system should be designed to evolve through the addition of new services. This is called a Service Oriented Architecture (SOA). SOA defines the services that are used to compose a system and then maps these into a physical implementation. As a design pattern, SOA provides services to application consumers through standard-based, published, and discoverable interfaces. From a developer s perspective, this elevates code reuse because it allows applications that can bind to services that evolve over time. Also, this provides a clear integration model between systems both inside the enterprise and across organization boundaries.

The Benefits of a Service Oriented Architecture

As we begin to develop applications, it s important for us to understand the benefits of an SOA. They are:

Focused Developer Roles: SOA forces applications into tiers or application layers. Each layer provides a set of specific developer roles. For example, a database layer needs developers with Structured Query Language (SQL) experience. The presentation layer needs client-side programmers. SOA allows developers to specialize and organizations to rely on these specialists to develop their applications.

Better Return on Investment: The isolation of services into distinct business domains allows the service layer to exist beyond the lifetime of any of the composed systems. For example, if an application needs a credit card authorization routine, developers have two choices. They can create a separate component that services just the single application, or they can create a component that services all applications. If the credit card authorization is developed as a separate component and used as a service, then most likely it will outlive the original application.

Location Independent: Location transparency is an essential element of the SOA. The lookup and dynamic binding to services means that the client application doesn t care where the service is located. The natural extension is that services become mobile from one machine to another.

Tighter Security: The separation of an application into services naturally allows a multi-level authentication scheme. Each service can implement a security scheme that makes sense for the sensitivity of the data it presents and then provide additional security layers based on the services they use.

Better Quality: The independent and isolated nature of SOA provides easily testable software units. Services can be tested independently of any application that uses the service. This allows developers and QA to provide a more focused testing suite that will result in better software quality.

Multiple Client Support: SOA makes it easier to implement multiple clients and types. The splitting of software into layers means clients can access services using whatever protocol or methods make sense for the client. For example, a Pocket PC can use the Compact Frameworks, and an ASP.NET Web page can directly call a Web Service.

Natural Code Reuse: The biggest reason code reuse has failed in the past is the general language and platform inconsistencies. The architecture of a service creates a catalog of evolving reusable components. Applications are able to automatically understand and implement components in the catalog. Additionally, the catalog is flexible and secure enough to allow new uses of existing components and secure enough to ensure data safety. Developers no longer have to worry about compiler version, platforms, and other incompatibilities that make code reuse difficult.

Lower Maintenance: This service layer provides a central location for all business logic. This area enables developers to locate and correct software areas quickly and doesn t require them to compile the entire application.

Faster Development Time: Multiple software layers means multiple developers can work independently of each other. The creation of interfaces guarantees that the individual parts are able to communicate.

Scalable Architecture: The use of location transparency guarantees better scale and availability. Multiple servers may have multiple service instances spread across multiple locations. Fail-over and redundancy can be built on the service end so that clients don t have to worry about implementing specific network features.

What Services Are

Services are really nothing but discrete units of application logic that expose message-based interfaces suitable for access across a network. Typically, services provide both the business logic and state management relevant to the problem they are designed for. When a developer or application architect is designing services, the main goal is to effectively encapsulate the logic and data associated with the real-world process. It is important to pay careful attention to what to include and what to implement as a separate service.

State manipulation of a service is governed by business rules. These rules are relatively stable algorithms, such as the method in which an invoice is totaled from an item list, and are typically governed by application logic. On the other hand, policies are less static than business rules and may be governed by regional or customer- specific information. Policies are typically driven from lookup tables at runtime.

Services are network-capable units of software that implement logic, manage state, communicate via messages, and are governed by policy. When defining a service, make sure to identify its specific responsibility within the system. This ensures that the service acts independently within a multi-tiered application.

A service is similar to a component or an object. The big difference is that a service doesn t have an instancing model. It basically sends a message to a destination and hopes that it will both arrive and be responded to by another message. Service interfaces are designed to expose functionality. A component or an object interface defines what the method calls should look like. Also, the service interface defines what the message and its sequencing should look like.

Messages are the units of information transmitted from one service to another. These must be highly structured with both sides being either aware or able to discover the format of the message. Typically, this is communicated through the use of schemas. These structures must be clear enough to contain or reference all the information necessary to understand the message. This is the basic concept that allows communication between different technologies and allows you to choose an appropriate technology for every new service. Many times, this is referred to as the idea of loosely coupling .

A message is not just a function call. The loose coupling allows messages to pass through both system and process boundaries. Often, they are processed asynchronously and in any order; it s not guaranteed that they will be delivered multiple times or that an immediate response will be received.

Web Services

Web Services are one of the core components for the development of a services-based architecture. Technology alone doesn t make the services. It is important that components be designed with a loose coupling ”as we will throughout this book. This is the ideal scenario that Office is able to take advantage of and provides the greatest application flexibility. Most of the applications developed within this book are based on the SOA and focus on the use of Web Services.

Web Services Architecture

The .NET Framework supports a variety of managed application types. These include the traditional Windows Forms, ASP.NET, mobile applications, and Web Services. Web Services are important because they provide self-contained business functions that operate over the Internet or an intranet. They are written to a strict set of standards that ensure they are interoperable and callable from other Web Services or front-end applications like Windows Forms or Microsoft Office.

Web Services are important to a business because they quickly enable interaction between different systems or processes. Web Services allow companies to provide data electronically using a set of reusable and discoverable interfaces. Many of the applications that we will build throughout this book use Web Services to provide back-end data access or integration.

The architecture of a Web Service, as shown in Figure 1.2, is similar to a Remote Procedure Call (RPC) over HTTP using XML as the message payload. The RPC portion of the Web Service implements the Simple Object Access Protocol (SOAP) to manage the underlying communication architecture. SOAP defines structured XML messages that ride over any type of network transport, although typically HTTP is used. These messages contain addressing and routing information that determines the delivery of their XML payload. The use of XML guarantees that they are firewall friendly and system independent.

Figure 1.2: Web Services are a stack of technology that enables the creation of a service.

While SOAP provides the intersystem messaging structure, the Web Service Description Language (WSDL) describes the set of operations within each service that the server supports. WSDL is an XML-based file that acts as a service contract between the server and client of a Web Service. As part of this contract, the server agrees to provide a set of services as long as the client provides a properly formatted SOAP request.

As Web Services are created, the UDDI enables the lookup and discovery services for Web Services. UDDI provides the yellow pages lookup that allows clients to dynamically discover and consume Web Services. There is a public version of the UDDI registry as well as a private one. For the purposes of this book, all code examples are using the private version included as part of the Windows Server 2003 operating system.

Creating a Simple Web Service

 CD-ROM     To illustrate what we have talked about, let s walk through a simple Web Service that returns the current server time (this is covered on the CD-ROM in the Chapter 1 samples directory ”\Code\Chapter 1\FirstServiceSetup\Setup.exe).

Open Visual Studio.NET and create a new ASP.NET Web Service project named FirstService, as shown in Figure 1.3.

Figure 1.3: Within Visual Studio.NET, select the type of project that you want to create.

Once you have selected the project, you are brought into the design palette. In order to write code, we need to switch to the code window, as shown in Figure 1.4.

Figure 1.4: Visual Studio.NET provides both a design palette and code window.

XML Web Services consist of an entry point and the code that implements the XML Web Service functionality, as shown in Figure 1.5. In ASP.NET, the .ASMX file serves as the addressable entry point. It references code in pre-compiled assemblies, a code behind file, or code contained within the .ASMX file. The WebService processing directive at the top of the .ASMX file determines where to find the implementation of the XML Web Service. When you build an XML Web Service in managed code, ASP.NET automatically provides the infrastructure and handles the necessary processing of XML Web Service requests and responses, including the parsing and creation of SOAP messages.

Figure 1.5: The code window within Visual Studio.NET 2003.

In order to expose a method as part of the Web Service, place a WebMethod attribute before the declaration of each public method. This attribute tells the ASP.NET runtime to provide all of the implementation required to expose a method of a class on the Web. This includes creating an instance of the WSDL necessary to advertise the service on the Web.

Once the Web Service is compiled and run, it can be accessed from a Web browser and passed a valid query string. The .ASMX file returns an auto-generated service help for the Web page, as shown in Figure 1.6. This service help page provides a list of the advertised methods available for this service.

Figure 1.6: The compiled Web Service running in a browser.

Additionally, this page contains a link to the XML Web Services description document. The service description page provides the formal XML WSDL definition for the Web Service, as shown in Figure 1.7. This XML document conforms to the WSDL grammar and defines the contract for the message format that clients need to follow when exchanging messages.

Figure 1.7: The auto-generated WSDL for the Web Service.

The service method page provides additional information that relates to a particular XML Web Service method. The page provides the ability to invoke the method using the HTTP-POST protocol, as shown in Figure 1.8. At the bottom of the Web page, the service method help page provides sample request and response messages for the protocol that the XML Web Service method supports.

Figure 1.8: The compiled Web Service running in a browser.

Once the service is invoked, a new browser window is open and the returned XML message is displayed, as shown in Figure 1.9.

Figure 1.9: The returned XML message from the Web Service.

Congratulations! We have just walked through the creation of our first Web Service. Throughout the course of this book we will build many more, but it is important to understand the steps necessary to build and use a simple Web Service. Now let s move on to how we can use these services.