Implementing SOA in VS 2005

Home

	Introduction
	This is a demonstration intended to teach .NET developers how to implement simple Service Oriented Architectures (SOA's) using the new features in Visual Studio 2005. It assumes a working knowledge of the Visual Studio IDE and a .NET language (VB.NET, C#, J#, etc). It is not intended to provide comprehensive information about SOA design or the new version of Visual Studio, but instead give developers a taste of the environment and show how to implement basic SOA concepts.
	Visual Studio 2005 The biggest leap in the product line since Visual Studio 2002, the new version that just entered public beta contains countless features that aid in developing complex, connected applications. In this demonstration we will look at 2 new features, the Application Connection Diagram and the Class Diagram, as well as some features that you as a developer may not have used, such as web services and web service debugging.
	Web services and Service Oriented Architectures For those unfamiliar with web services, they are a mix between a traditional web application (seen in previous versions of ASP, CGI, PHP, etc) and legacy protocols like DCOM and RPC. Hosted in a web server, web services allow the developer to expose methods that can be called from outside of the service. Using SOAP, a technology for message passing over HTTP using XML, it is possible to invoke (or call) a method on a web service from any kind of application or environment that can support web browsing! Web services are usually designed to be called behind the scenes by other applications, and not directly interact with users. Typical consumers of web services are other web services, traditional web applications, or thin clients. The Web Service Definition Language, or WSDL, is used to provide information about web services to consumers, including the methods exposed and their formats. In this demonstration we will be implementing web services on .NET, which uses IIS as a host and ASP.NET for all of the internal support. The nice thing about using ASP.NET is that when creating web services the developer can serialize .NET objects over the internet via SOAP, meaning no extra work needed. This allows methods like 'MyUser GetUser(string name){}' where MyUser is a custom class and string is the native .NET string type. Consuming web services in .NET is incredibly easy, as Visual Studio will automatically generate the WSDL for you and create client calling code from it. By simply adding a reference to a web service, you can call it as if it were a class in the application you are writing. For more information, see the links at the bottom of the page.
	Service Oriented Architectures Service-oriented architecture is really just a buzzword for the client/server model of data consumption that has been around for ages, however it has recently been turned into a more specific kind of design philosophy. The basic tenants of SOA are that services should abstract their internals, maintain a consistent public interface, and services can consume other services. An example of the power of SOA would be an inventory management system. In a traditional system, a developer may have a client that is used by end users and a collection of servers that handle different aspects of the operation; one for billing, another for item tracking, and so on. The client would have to connect to each of these services and know every detail about them; a change in any of the services would require a new version of the client, leading to management nightmares. In the SOA world, the same set of applications and services would exist, however there would be a single connection point between the client and the 'first tier' service. This service would act as an aggregator, exposing a standard interface for anything the client would want to do, and then internally making use of the other services. Instead of the client needing to know the protocols for talking to the billing server, connecting to it (possibly with a unique authentication system), and having to deal with it's ever changing interface it can now just rely on the first tier service to get it right. Imagine 10,000 of these client applications out at end users and a change in the billing protocol arises; a simple fix to the first tier service and everything runs smoothly again, where as with a traditional system you'd have 10,000 updates to perform. Again, SOA is really just a design philosophy for building connected applications cleanly. Also, keep in mind that a service can consume other services; in the previous example this means that the billing service can also consume credit card, customer tracking, and invoice creation services which, in turn, may consume other services. For more information, see the links at the bottom of the page.

	What we will be doing
	The goal of this demonstration is to build a simple SOA with Visual Studio 2005. For this, a simple scenario has been devised. Imagine that you are a developer in a small business, and you currently have an old Access database with a list of phone numbers. You have just acquired a new content management system that lets you get lists of people for certain purposes (say, all customers, or all employees). Your goal is to create a way to combine these two services; the legacy phone book and the new directory service. Finally you need a new way for other employees to access this information, so you will need to build a new client application. This breaks into 3 distinct projects, whose purpose will become clearer as you implement them:
	LegacyPhoneBook This is a wrapper around the old phone book database that allows callers to search for a phone number by using a persons name. It only needs to export a single method, called 'Search', to serve this purpose.
	DirectoryProvider This project is the new service being implemented; it returns a list of names to the client (method 'GetPeople') and also allows the client to get a phone number for a person (method 'GetPhoneNumber'). The method GetPhoneNumber is simply a pass through to LegacyPhoneBook. The reason we are wrapping it up here is a core concept of SOA's: we need to abstract all the backend work, and make it simple for the client to deal with. By doing this, the client only needs to know about DirectoryProvider, and in the future we can replace the LegacyPhoneBook service with a new integrated solution or web search without having to change the clients at all.
	MySoaClient This is a simple client that will consume DirectoryProvider by listing the people and allowing the user to get phone numbers for them.

	Requirements
	Windows 2000, XP, or 2003 running with IIS installed; the current ASP.NET 2.0 beta requires IIS for web services.
	Visual Studio 2005 Enterprise Architect beta 1; the Express products may work, but do not contain many of the features shown here.
	A working knowledge of Visual Studio 2002/2003/2005, and experience in VB.NET or C#.

	Warning
	If you do not know how to properly administer an IIS server, please do not continue until you have read up on it! Leaving an insecure IIS server online is the quickest way to get your system exploited!
	Microsoft IIS Best Practices

Using this demonstration

Navigate the slides of this demonstration using either the buttons at the top of the page or by clicking on the screenshots when availiable to progress to the next slide.

Terms that are defined in the glossary will have the

icon next to them. Click on it to be taken to the glossary.

Several icons are used in the demonstration to denote actions or identify sections:

	Task block; information about the tasks to be performed follows.
	Task item; this line tells what needs to be done.
	Warning; possible error here, or something to be aware of.
	Extra information.
	Code; this is code that needs to be entered, copy and paste is the easiest way to move it.
	Web link; link to extra information or resources.

See Also
	SOA / What is SOA?
	.NET SOA Center
	.NET Web Services