During a recent project it became very clear to me that standardization (naming conventions, coding guidelines, etc.) is also a very imported issue within a service oriented environment. Probably because of the service orientation hype, everybody is too busy with all the service oriented related issues within the project that make them forget very basic things (like coding standards and guidelines).

Because of the autonomous nature of a service it is very likely that they are developed by different people (or teams). From what I saw in practise, communication between the several build teams of the different services within a solution is very limited, simply because of the fact that the interfaces are well defined (if the designer understands it’s job).  In case there is communication between the different service teams, it is mostly about the service interface and messages definition, rather than internal implementation (coding) issues. In case of a lack of standards, guidelines, etc., the end result of this is a solution (application) that exists out several services all implemented in a very different way, using different naming conventions, exceptions handling strategies, etc.

Of course missing standards and guidelines can cause the same issues (poor quality of code) in an “old fashioned” n-tier application but, because of the more tightly integration between the different parts or components in the application, developers tend to communicate more and they are more often (forced to) have a look at each other code. This will result in at least the same “standards and coding techniques” used within the whole application.

Because I have some time of in the last few days of this year I was looking for some coding stuff that I could do. To prepare for the (near) future, I decided to try upgrading the EDRA 1.1 bits to .NET framework 2.0. Just because I was curious how much time was involved in upgrading code like this. I installed the latest available release of Visual Studio 2005 and after opening the Reference Architecture solution in VS.NET 2005, the upgrading wizard left me with a little more than 100 errors and warnings. As you can see in the (very) short list below, most of the errors and warnings are because the EDRA bits are using 1.1 .NET framework parts that are obsolete in the .NET framework 2.0.

·          'System.AppDomain.GetCurrentThreadId()' is obsolete: 'AppDomain.GetCurrentThreadId has been deprecated because it does not provide a stable Id when managed threads are running on fibers (aka lightweight threads). To get a stable identifier for a managed thread, use the Thread object returned from Thread.CurrentThread.'

·          'System.Xml.XmlValidatingReader' is obsolete: 'Use XmlReader created by XmlReader.Create() method using appropriate XmlReaderSettings instead. http://go.microsoft.com/fwlink/?linkid=14202

·          'System.Xml.Xsl.XslTransform' is obsolete: 'Use System.Xml.Query.XsltCommand instead.

After a few hours of coding and searching the Visual Studio 2005 online documentation this is how (part of) my laptop screen looked like:  

I haven’t done any testing yet, I will do that the next coming days. But he.... at least it compiles!

I finally found time to do some testing with the ‘WSCF’ tool of thinktecture that Christian Weyer is blogging about. Installed the tool and followed the walk-through document. Cool!

Last week we decided to do an upgrade of EDRA 1.0 to EDRA 1.1 on our development machines. According to Microsoft, version 1.1 is the final version of EDRA. Microsoft indicates that in the beginning of next year they will start a similar project to take on the latest distributed design challenges using Microsoft’s BizTalk and "Indigo" technologies.

After making the change described my previous posting in the Microsoft EDRA 1.1 code, we compiled the EDRA 1.1 code using our own public key. After that we compiled our ‘EDRA extensions’ against the new EDRA 1.1 assemblies. Only one code change was needed to make all our code compile (Microsoft decided to change the name of one of the Handler Interfaces). Further the following changes were needed to make our test services work:

·         Remove ‘ra’ namespace prefix in ServiceReferenceArchitecture.config.

·         Move Pipeline configuration from ServiceReferenceArchitecture.config to the new ‘TemplateServices.config’ file.

·         Add two new configuration sections to specify the location of the ServiceReferenceArchitecture.config and the TemplateServices.config file.

Based on the results of our NUnit test, everything worked as expected (after the changes described above).

To make absolutely sure services implemented using EDRA 1.1 behave the same as services implemented using EDRA 1.0 we also did some manual testing against our test services. After that we had enough confidence to advice a project that is using EDRA 1.0 at this moment to do the upgrade to EDRA 1.1.

All the project has to do now is: install the new EDRA 1.1 assemblies; install the new version of our ‘EDRA extensions’; make the necessary changes in the configuration files; start system testing!

Currently, I am working myself through the WS-Policy specification. When doing this I found this very interesting article of Aaron Skonnard in which he explains how to use WS-Policy for webservice validation. The technique Aaron describes makes it possible to completely decouple validation logic from the webservice implementation, which of course improves service maintainability. After reading this article I decided to not only study the theoretical part of WS-Policy but also do some coding with it.

As I am doing some work with Microsoft EDRA at this moment, I decided to try to integrate WS-Policy into EDRA. Out of the box EDRA only supports schema (xsd) validation, so the technique Aaron describes can be very useful.

I haven’t done any testing with EDRA and WSE 2.0 yet, but according to Microsoft it must be possible. I actually do see some issues in integrating WS-Policy (WSE 2.0) and EDRA. These are not really technical issues. I think, when using WSE 2.0 and EDRA together, the WSE pipeline gets executed first. I am also almost sure that this isn’t easily changed (haven’t tested this yet). This means when using WS-Policy for doing some business validation and using EDRA for authorization, validation is executed before authorization is done. As I said, this is not a technical problem but can definitely be an issue. Of course using WSE for security is a very valid option to solve this issue.

I am very much aware that WS-Policy might change in the future and WSE doesn’t solve all related WS-Policy issues yet. One of the issues with WSE for example is the lack of policy discovery. WSE doesn’t provide a way to discover the policy statements of a service, so a solution must be found for this. In our situation, a possible solution for this is to store the URL for the service policy file together with all other service related info in our directory service. In this scenario it is at least clear where to find a service policy file if it exists.  

Although I see some issues, I think using WS-Policy in EDRA might be useful to get rid of business validations within the service implementation. I also think integrating it in EDRA doesn’t need a lot of work, so I will give it a try in the next couple of days.

Stay tuned!

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!

One of the things that can help keeping service interfaces stable are well defined messages. However, it is very likely that at some point in the lifecycle of a service, adjustments in the messages are needed to support new functionality. These versioning problems in messages can be handled very easily by making use of the [XmlAnyElement] and [XmlAnyAttribute] in the messages.

When we have a look at the XML schema standard we can see that it defines the “<any/>” item for arbitrary xml content and the “<anyattribute />” item for undefined attributes inside an xml document. We can use these two items to define XML schemas that are highly extensible. By using the .NET [XmlAnyElement] and [XmlAnyAttribute] attributes we can deliver this extensibility feature of the xml schema in the messages used by our services.

Using the above mentioned attributes is very simple. We can add the attributes to a field in our message. The “NormalMessageContent” field on the “SampleMessage” class below is the only field that is a fixed part of the message.The other two field are there to hold de “custom xml” (FlexibleMessageContent) and the “custom attributes” (FlexibleMessageAttributes).  

[Serializable]

public class SampleMessage

{

 

  public string NormalMessageContent;

 

 [XmlAnyAttribute]

  public XmlAttribute[] FlexibleMessageAttributes;    

 

 [XmlAnyElement]

  public XmlElement[] FlexibleMessageContent;

}

The XmlSerializer (deserialize) will store all unmapped (unrecognized) XML elements in the “FlexibleMessageContent” field. All unrecognized attributes are stored in the “FlexibleMessageAttributes” field. Basically any content in an xml document other than the “NormalMessageContent” element will be available in our service through the two “flexible” fields.

So, By adding two fields to our message and tag them with the above mentioned attributes we can create messages that support versioning very well. Besides using this technique for versioning we can also use this to standardize messages. By using the above approach it is also possible to create a message with a few standard fields (messageId, timestamp, etc.) and one field that is used for the actual message content. In theory this message can be send to every service. It’s up to the service to decide if it understands the message that is stored in the message content field of the message. Creating service interfaces with these kinds of standardized messages might be a good way to keep the services interface stable!

Besides working with EDRA I am also very interested in technologies (or products) like Indigo and FABRIQ. Both of course different products, but with some concepts in common. For me it’s important to understand the concepts of these new technologies so I can use this knowledge in my current work when it comes to making architectural/design decisions that are as future proof as possible. To get familiar with the concepts in both Indigo and FABRIQ I decided to try to introduce some of these concepts on top of EDRA.

For the record: this is all just for my own fun! I have no intention to use the result of this in my current work that I am doing with EDRA.

It is my intention to change as little as possible in EDRA (preferable nothing), so all new functionality will be on top of EDRA. The ultimate goal is to build an (small) application that is using concepts like messages and ports similar as they are available in FABRIQ and Indigo but using EDRA ‘behind the scenes’. All of course in a very limited version. Just enough for me to understand the implementation consequences of these concepts within an architecture.

One of the first things I noticed when looking at FABRIQ and Indigo is the similarity in the concept of the ‘message’. Both products have a well defined message class. This is something that is not available in the current release of EDRA. In EDRA a message is based on a XSD, each message is of its ‘own’ type and is not derived from, for example, ‘EDRAMessage’ class. Because I think a well defined and consistent message structure has some advantages compared to the way messages are handled in EDRA, I decided to first introduce the concept of a message (like FABRIQ and Indigo) in my ‘study project’.

If we look at the Indigo message class (FABRIQ message looks very similar) we can see that this is actually a ‘wrapper’ around a SOAP envelope. The message basically consists of two different parts, the message content and a collection of message headers. The message content part is used for sending application specific data from one service to another. If we take a better look at the message content, we can see that this is some sort of a ‘free format’. This means it is an unspecified structure. This is no problem because, as long as the message sender and the message receiver understand the message, everybody is happy. The infrastructure doesn’t need to understand the message content!

In indigo, the actual message content is reachable by using the ‘reader’ property of the ‘content’ object of the message class (Message.Content.Reader). This property in fact returns an XMLReader positioned at the beginning of the ‘soap:body’ part (= actual message content) . Using an XMLReader for accessing the content of a message has some advantages. When Indigo (and FABRIQ) creates a message it uses an XMLReader to first read the ‘soap:header’ part of the message. As soon as it finished reading the header information it stops reading and leaves the XMLReader positioned at the beginning of the message content (soap: body). The message content is then available by using the reader property as shown above. Treating a message like this, saves an enormous amount of time (especially for large messages) because the whole message doesn’t need to be loaded in some sort of a DOM before the infrastructure can do its magic to process the message. In fact, the infrastructure doesn’t need the message content at all.

When we look at the message headers, the story is a bit different. Message headers are needed by the infrastructure to process the message. The infrastructure can even change headers if needed. Because headers are used by the infrastructure most of them are system defined. The message headers are reachable (Indigo) by using the ‘Headers’ property on the message class. Message headers are added (or even changed) to the message by the infrastructure and NOT by the sending or receiving application. Headers can be used by the infrastructure for, routing, security, etc. One very obvious header is the ‘to-header’. This header holds the URI of the receiving application (service) and is used by the infrastructure to deliver the message at the right spot. Preferably the ‘to-header’ isn’t populated by the sending application but by a part of the infrastructure (directory service). This guarantees location transparency between services or applications. Another very common message header is the ‘action-header’. This header isn’t used by the infrastructure but is used by the receiving service of the message. This ‘action-header’ can be used by the receiver of the message to internally map the message to the right  place in the service or application that is capable of handling that specific ‘type’ of message.

So, where are we? I used the above to organize some of my thoughts and learning’s about messages in Indigo and FABRIQ. Although the concepts of messages and headers are available in EDRA they are implemented in a very different way. My next step will be defining a (very basic) message class en probably two header classes (to- and action- header). The message class must be capable of wrapping an EDRA message (XSD typed message) and supports storing the headers. The implementation of the message class and headers must be just enough to support the concepts described above. After that I will dive into the concepts of ports and channels and implement these concepts in a very basic way. When this is finished I will try to map these things to the EDRA pipeline and see if I can get all off these things to work together….

Of course the big question is: is it worth it to spend time on the things I planned to do?

Well…..maybe not, but at least it helps me understand new concepts and gives me some fun!