Merit Matters Blog - Web Services

What is Service Oriented Architecture (SOA)?

nospam@example.com () — Tue, 19 Aug 2008 06:10:00 -0400

Confused with term SOA?

I'll help you understand the basic principles that stand behind what we call a Service Oriented Architecture. If you just want a simple, one sentence explanation, here it comes: SOA is a new approach to building IT systems, where logic is decomposed into smaller, distinct units.

Those units are called services. Seems like nothing new, but what makes SOA special is the set of design principles. Before we discuss the principles of SOA design, let just make it clear what really defines a service.

As you already know, "service" is a very widely used term. We use it in IT as well as in everyday life. For example, your favorite restaurant is a service. You come in, take a look at the menu, make an order and what you get is a (hopefully good) meal. Let's take a taxi as another example. When you take a cab, you expect it to take you from Point A to Point B - and you would certainly like to make it in a reasonable time.

Now, let's try to make some general conclusions about services:

In order to use a service, one must provide it with some parameters (in a restaurant, you must tell to a waiter what would you like to eat and drink; cab drivers must know where would you like to go).
Service users expect its state to be changed in some way (you enter a restaurant hungry, but you are fed up when you are done; before taking a cab, you are on one street and after it you might be in completely different part of a city).

So, you must know how to use a service and what result to expect. The same stands true for services in the IT world. When trying to build SOA, your services have to be designed in a certain fashion.

Here are the principles that have to be followed:

Service contracts - All services must adhere to some kind of communication agreement. In order to make services communicate, the messages that they exchange have to be described precisely, as well as arguments that each service requires. You won't get what you want in a restaurant in England if you speak Chinese.
Loose coupling - Services should be as independent as possible (e.g. they should just retain an awareness of each other) without making tight connections that are hard to break if something has to be replaced or changed in the future.
Abstraction and Autonomy - Services just give you what you need, not letting you see how is it accomplished. You just care about the interface. In our restaurant example, you don't really care how your meal gets prepared, you would just like to eat. Also remember that some recipes are secret! Furthermore, a restaurant is autonomous and has full control of what ingredients they use to prepare your meal.
Reusability - When we divide our business logic into services, we do it in such a way that enables us to use some of these parts in the future, without having to reinvent the wheel. Ideally, the purpose of reusability is to write a line of code just once - anyone else in the world won't have to write it again.
Composability - We can form composite services, by assembling collections of them. Statelessness Services tend not to keep any kind of internal information that will affect the result of their work. Arguments that service users enter should be the only thing that matters.
Discoverability - Once created, services should be descriptive and easily reachable. There should be a mechanism to inform all potential users (humans or other services), so that they can get the services automatically when need arises.

I hope now you have a global picture of what SOA tends to be. For further information, I suggest you start exploring various books that cover this material in detail.

Some Free Web Services

nospam@example.com () — Mon, 11 Aug 2008 10:02:00 -0400

There are many articles on how to write and deploy your own Web Service. Here, I will show you where you can find Web Services that other people have created and made public.

Many interesting Web Services that you can use free of charge can be found at: http://www.webservicex.net http://www.wsoogle.com. This may be particularly interesting when you are developing Web applications. For example, you would like to have some kind of currency conversion in your Web app. However, exchange rates are different every other day and you would certainly want to automate the process of their updating. One way to solve this problem is to use an existing Web service and don't think about the rates at all! A good example of what you might need is here. Just supply the service with two strings that represent currencies and you get back an exchange rate as a double!

Other services you may find interesting are different types of calculators, credit card checkers, translators, etc... These will certainly help you develop your application, no matter which tools and programming languages you use. However, be careful and note that all those Web Services are not under your control. If some change to their interface or implementation occurs, your application may change its behavior! In any case, there is no doubt that you will find some of them useful. You may also get an idea to build your own Web Service that many people would like to use. Good luck!

Windows Communication Foundation

nospam@example.com () — Fri, 01 Aug 2008 04:33:39 -0400

.NET Framework 2.0 relies on several distributed programming technologies. Maybe you are already familiar with Web & Enterprise Services, .NET Remoting, WSE... All these technologies have some advantages and drawbacks that make them more or less suitable for performing certain tasks.

For example, when creating an application that is supposed to be distributed over the Internet, on different machines with different operating systems, Web Services are what we need, because they offer an elegant and unambiguous way for different kinds of machines to communicate.

If our distributed application is going to run in company LAN (or maybe even just on local machine), on computers that all run .NET Framework, interoperability is not really a problem, but we would like to optimize the communication and get the best possible performance. Here, .NET Remoting is the way to go.

However, there are situations when it is necessary to combine different technologies in order to accomplish a given task. Although this isn't impossible, it may be expensive, hard and tricky to develop and maintain such a system. As a response to such situations, .NET 3.0 offers (and .NET 3.5 improves) something called Windows Communication Foundation (or simply WCF). The basic idea behind WCF is to integrate all distributed technologies that existed in older versions of .NET framework and put them under one roof, so they can be used easily and in the same fashion together.

Furthermore, WCF is a natural foundation for applications that follow SOA (Service Oriented Architecure) principles. For example, the concept of service contract is depicted as an interface. You define and implement a service contract simply by creating and implementing an interface! If you would like to take a deeper look at WCF and its possibilities, this MSDN page is a good place to start: Have fun!

Creating and using custom SOAP headers in Visual Studio 2005

nospam@example.com () — Mon, 28 Jul 2008 05:03:55 -0400

Web Services are a cool, platform and language independent way for applications to communicate. You may already know that peers use SOAP messages, based on XML, to make the communication possible. In this article we will learn how to create and use custom headers in our Web Services. We are going to use Visual Studio 2005 and C#, but things are not much different in VS2008.

The SOAP envelope consists of body and header parts. While the body element is mandatory and has a predefined structure, the header is entirely optional and you are free to use it any way you like.

For example, let’s try to make some kind of authentication header – one that contains a username and password.

To be clear, we wish to add the following header to every SOAP message that a client sends to the Web Service: <authenticationtoken> <username>myname</username> <password>mypassword</password> </authenticationtoken> First of all, we have to create a new class that inherits System.Web.Services.Protocols.SoapHeader, assuming that you have already developed your Web Service. In a project that represents your Web Service, add the file named AuthenticationHeader.cs, with the following code: public class AuthenticationHeader : SoapHeader { public string username; public string password; }

Next, we have to change the class that represents the Web Service by adding a public member of AuthenticationHeader type: public AuthenticationHeader header;

Now we need to specify the methods that will use the header (if our Web Service has more than one method, some of them may require authentication while others may not).

We can accomplish this by adding attributes: [SoapHeader("header", Direction=SoapHeaderDirection.In)] Here, the string argument represents the class member where the header is stored after deserialization (in our case it is named “header”). "Direction" specifies who is supposed to send SOAP headers – a client, the Web Service, or both. "In" means that Web Service just receives the header, so client is the one who composes and sends them. Other possible values are Out (Web Service sends the header), InOut (the header is sent in both directions) and Fault (the header is sent by the Web Service, but only if some exceptions, faults etc. occur).

In the method body we can process the header as we wish. In our example we would like to check whether the credentials are valid or not. We won’t make any sophisticated checks here, let’s just put a simple if statement at the beginning of the method: if (header.username != "uncle" && header.password != "sam12345") { throw new Exception("Incorrect login!"); }

We may now recompile our Web Service. Its WSDL description has changed, so we must update Web References in all clients that use it. After updated, a new member, named AuthenticationHeaderValue, will be generated in the proxy class. By setting its value we actually form the SOAP header in runtime.

For example, if a proxy object is named myService, here’s the piece of the client code: AuthenticationHeader ah = new AuthenticationHeader(); ah.username = "uncle"; ah.password = "sam12345"; myService.AuthenticationHeaderValue = ah; myService.PerformOperation();

Note that we could use a method argument here to accomplish the same thing, but this is certainly a more elegant way, since we want to make the interface of our Web methods focused on real functionalities.