Currently there is a bit of a discussion going on within our team whether to use the Remoting interface for services or not. When using EDRA, Remoting is one of the possibilities for creating a service interface, the question is: is Remoting the best option to use?

One of the ideas is to use a Remoting interface for ‘business information’ services and a webservice interface for the ‘business process’ services. I think this decision is primarily driven by a better performance that Remoting is supposed to bring us.

Personally I am not sure if performance is the best thing to base a decision on in a SOA environment. Using services implies crossing boundaries. Crossing boundaries is expensive by default! Of course Remoting can give some performance gain in this case in comparison to webservices but this shouldn’t be an issue in my opinion. If performance is what you want, don’t cross boundaries, don’t use services.

Another disadvantage of using Remoting for services is the lack of security. Of course using one of the EDRA handlers (or a custom handler) can provide some sort of a ‘security solution’ but security isn’t embedded in the design of Remoting.

It’s not that I don’t linke remoting because I do. Remoting can be very useful when using it internally in an application; in some scenarios it can be much more appropriate than using webservices. I only think Remoting shouldn’t be used across application (service) trust boundaries.

In my search for information about designing a service interface I came across some interesting postings of Aaron Skonnard about “contract first approach” for developing services. It looks like some guys are having some very interesting ideas about this. As I can read from there postings there isn’t yet very good tool support for this way of developing service contracts. Christian Weyer is having some thoughts about tool support for this. I haven’t had the time to dive into this, but certainly will very soon!

Although there are tons of articles covering SOA related issues on the internet, there is very little info about ‘defining a service interface’. During some support work that I am doing for a project at the moment I noticed that it can be hard for a software designer to define its ‘first’ service interface. Probably this is because defining an interface for a service is a little different than designing an interface for a component. I tried to find some guidance on this in the form of an article or document on the internet but couldn’t find any of this. Of course there is information about this but all in very small pieces in several articles. I tried to collect some of these pieces of guidance into one document so this can be used when defining a service interface.

Below some (maybe) helpful tips:

Define “business actions” on your service interface and not CRUD actions: Try to think of a service action as something that performs a real business task and not only an insert or delete in a database table. An “add” service action on the “Order” service implies that it only does an insert in the Order table, but maybe in reality it also checks the creditability of the customer that is placing the order. In this case a service action called “Add” doesn’t reflect the real business action.

Define the service interface as explicit as possible:  a service with an explicit service interface (contract) is much easier to consume than a service with a more “general” interface. It must be clear from the interface what kind of action is executed by a service action(s). This means, a service with an “execute” service action might not be the best thing to do. (I know I wrote some about a “generic” service interface in a previous posting but this was only to demonstrate the “message flexibility” that can be achieved with “[XmlAnyElement]”).

Avoid leaking internals: try not to leak service internals to the outside world. So, don’t expose for instance a .NET dataset on the service interface. Define messages based on an Xml schema (XSD). Also make sure not to include “technical attributes” in your messages. One way to make sure you don’t leak internal in your messages is to define your messages before you design your service implementation. When doing this, you cannot leak for instance technical attributes because you simply don’t have them defined yet!

Define coarse grained service interfaces: in general, coarse grained services have more business value and are easier to consume. I think trying to expose business actions instead of crud actions helps defining “coarse grained” services. Personally I think “coarse grained” a bit of a vague statement. I think coarse grained depends on the situation. Let’s call it right grained!

Above some of the things I try to keep in mind when defining a service interface. If you have any comments or additions, please let me know!