The purpose of this guide is to provide guidance for using Microsoft BizTalk Server 2006 R2 with Microsoft Windows Server 2008 Hyper-V. The emphasis is on BizTalk Server, but the performance evaluation methods and performance testing scenarios are useful Read More……(read more)
In this article, former Orbitz lead architect Brian Zimmer discusses scalability worst pratices. Topics covered include The Golden Hammer, Resource Abuse, Big Ball of Mud, Dependency Management, Timeouts, Hero Pattern, Not Automating, and Monitoring. Read More……(read more)
I had originally used the title ‘This week in downloads’…well, because there were downloads. 🙂 But this feels a bit like hollow advertising, and I may shop around for a new title (suggestions are always welcome), but I’ll go with the very bland ‘Weekly Update’ title for now.
New to the web this past week:
Otherwise, we are continuing to focus on building out materials that will be appearing in the month of September – new MSDN pages, new articles, and a couple virtual labs.
During my holidays my colleagues at U2U have released several pretty cool SharePoint tools/extensions. I’m just going to list them, if you want to learn more about them, check out Karine’s blog.
On top of that Karine has updated her famous CAML Builder Feature with the following enhancements (more info and download):
I know, it sounds odd in the modern world where code reviews are almost like one of the Sacred Commandments, that is taken religiously and you could be burned at the stake for not respecting it. So, please, hold with me for a little heresy No, I don’t argue that code reviews are valuable. It’s just everything in this world has cons and pros, and I’d like to discuss one unusual “con” of code reviews that usually does not come to light.
Anyway, imagine a small team very busy doing the work, that is, new features for your product. I stress that: everybody is busy. No kidding, real busy. And, surprise!, just like every other product, yours has bugs. And bugs are to be fixed, right? Right.
Now, how you’d fix a bug? There are generally, two philosophies about fixing the bugs. Well, may be more, and of course, there is that stupid “just fix the bug”, which completely ignores metaphysical side of the things we are discussing right now, but let me ignore this one for a while. So, these two approaches are patching vs. refactoring.
Now, what would you think is the right way to fix bugs? Admittedly, there are cases when patching is acceptable Examples? Quick Fix Engineering patches. Products, which are really done, and the less you touch them the better. Fixing embedded code of a space station passing a Jupiter, where every byte of the fix increases the chance of the whole fix to be corrupted and disable a multi-million irreplaceable spacecraft.
However, in most cases and in what’s considered “good engineering”, I strongly believe that refactoring is far superior to patching. It does not mean that every small bug requires complete rewrite of the product, not at all. But it means that you have to consider a bigger frame and not be afraid to change quite a bit, if necessary.
I know, I know, it sounds theoretical and questionable, so let me give you an example. Considering short size of an article, I’ll have to give a very simplified example, but quite a valid one nevertheless. Suppose, you have a method called DownloadCompletedInstant(), which is a callback at the moment, when some download is completed. In fact, all it does is to allow you to start downloading the next file. You find a bug, when one of our colleagues added to it something really really stupid, because he was confused with “Download completed” part of the name. In fact, it would not be stupid, if it would be in DownloadCompleted() callback instead of DownloadCompletedInstant() one. So, now you have two options:
1. Just move your colleague’s code from DownloadCompletedInstant() to DownloadCompleted()
2. Same as (1) plus renaming DownloadCompletedInstant() into ScheduleNextDownload(), hence avoiding a chance of future confusion.
So, what would you do? (2), clearly, right? However, there is a little problem. The renamed call is used in ten other files. So, although the change is microscopic, it affects much more files than a simple patch.
Now, your team is doing code reviews, so what’s the higher chance of getting it fast – posting a change with just a few lines of changes in a single file, or a changes with several dozen lines changed in a dozen or so files? And don’t forget, you want it fast. In part, because you want to fix the bug and get to the next, in part, because you don’t want the fix sitting on our computer and not being checked in. But! Everybody else is busy too. Everybody else has their own bugs. So, naturally, you would rather get a change with minimum affected lines just to get your colleagues do code review faster.
The result? The product gets a patch, not refactoring, and in a couple of months somebody will again misuse DownloadCompletedInstant() for something else, as bad as this time or even worse.
So, does it look right? Is it just me or is there a real problem somewhere here?
I’ve needed to cast my BizTalk message as a System.String in a couple of occasions so I’m going to put it here to remember how to do it.
1. Create a Variable of type System.Xml.XmlDocument (I’m calling it xml_Temp here)
2. Create a Variable of Type string (I’m calling it str_MessageAsString here)
3. In the expression shape insert the following code:
//Instantiate your xml_Temp System.Xml.XmlDocument
xml_Temp = new System.Xml.XmlDocument();
//Assign the message you want as a string to your new xml_Temp System.Xml.XmlDocument
xml_Temp = msg_YourOriginalMessage;
//Assign the .OuterXml property of your xml_Temp to your str_MessageAsString System.String
str_MessageAsString = xml_Temp.OuterXml;
BizUnitExtensions 2.3
BizUnitExtensions crossed the 400 downloads mark recently and im really chuffed about that. One of the things I’ve been meaning to do for a very long time is to release some work i did with my previous project team in restructuring the codebase for Extensions. Basically, in alignment with BizUnit 2.3 we moved all […]
(click here for an index of the complete series, as well as supporting screencasts)
(click here for a screencast illustrating "Controlling the URI")
Resources in REST
Arguably, the most fundamental concept in REST is that of a resource. It is best to think of it as a conceptual representation of an entity or entities. Blah, blah, blah, conceptual, blah blah blah, representation, blah, blah, blah entity. What does all of that mean anyway? Think of it this way, if you can create a link to it, it is a resource. Now what does conceptual representation mean? Essentially, it means that the resource is an abstraction. It is not the underlying entity itself, rather a mapping to that entity… and that mapping may change. Whoa, the mapping may change? How is that? Consider the example that you wanted to expose the top 10 best selling books at your online store. The resource would be those top 10 best selling books. It is clear that those would change over time.
The need for the abstraction should be clear. In our previous example, we don’t really care what the back end was that stored the top 10 best selling books. It was, more than likely, a database system. It could have been Microsoft Sql Server, or it could have been Oracle or Informix or something altogether different. We don’t really care because we are not interested in the entity itself, rather the representation. If we were to switch back ends out after a period of time, it would be meaningless to us. The representation would be unaffected (although, as we argued earlier the representation might have changed). Further, imagine the complexity of the system where we were not mapping to the concept, but to the actual underlying entities.
URIs in REST
The way in which you identify a resource is through a URI. Section 6.2.1 of Fielding’s dissertation points out that "The definition of resource in REST is based on a simple premise: identifiers should change as infrequently as possible." He further states that "authors need an identifier that closely matches the semantics they intend by a hypermedia reference…" This points out the importance of the structure of the URI. Many folks try to create what I refer to as "Hackable" URIs. These are URIs that are easily remembered and whose structure and semantics are clear enough to manipulate. Take for instance the following URI: ‘http://www.someuri.com/Product/Flange’. It is pretty clear the the structure is: the http scheme and the hostname (‘http://www.someuri.com’) followed by 2 segments: Product and ProductName. A template for this might look like the following: ‘http://www.someuri.com/Product/{ProductName}’ where {ProductName} represents a variable.
You might argue that this is bad design, in that if the name of the product changes, so must the URI and that clearly violates the premise that a resource is based on. Another approach would be to use the ProductID as the final segment. I’ll leave that up to you. What I want to discuss in this post is what your options are for controlling the URI, assuming you have already designed how the URI should look.
The approach of this Post
If you have ever seen ‘What About Bob’ with Bill Murray, you will understand the following reference (if you haven’t, close your notebook, go to Blockbuster, rent ‘What About Bob’, come home, put it in the DVD player, open a beer – if that is your thang – and watch it). We are going to take baby steps to controlling the URI. I am going to start by outlining the default URI behavior when using the webHttpBinding along with the webHttp endpoint behavior. I will then show you what your options were in manipulating the URI structure via the UriTemplate. I’ll then move on to some additional functionality available in SP1. Lastly, I’ll illustrate how you can take complete control over the structure of the URI using IIS7 and the Url Rewrite Module.
The Sample
Below you will see the service contract and operation contract of our sample service. As you can see, the operation is named GetWine and takes in a string of wineID. You will also note that I have decorated the operation contract with a WebGetAttribute, making this callable via an HTTP GET. I have omitted the implementation, as well as the configuration, as they adds no value to this discussion.
[ServiceContract]
public interface IRESTWineService
{
[OperationContract]
[WebGet(ResponseFormat = WebMessageFormat.Xml)]
WineData GetWine(string wineID);
}
One other point to make is that address to this web is http://localhost/RESTControllingUri.
The Default Behavior
It may not be clear, but this operation does have a unique URI associated with it. The default URI scheme is the path to the *.svc file, followed by a segment with the operation name, followed by querystring parameters for each operation argument. The following represents the default structure of the URI:
[protocol]://[hostname][:port][/path][/svc filename][?argument1=value1[&argument2=value2 …]]
In the case of our example, it looks like this:
The UriTemplate
When we released the webHttpBinding and the webHttp endpoint behavior in WCF 3.5, we provided the ability to define a UriTemplate. Aptly named, the UriTemplate allows you to define a template for a set of URIs that follow a similar structure or pattern. The UriTemplate has 2 parts: the path and the query. The path is a series of segments. The segments can contain literals, parameters or variables and wildcards. Here are some examples:
The query contains name-value pairs that represent the querystring parameters collection. Here are some examples:
You can set a UriTemplate through code or you can pass it as a parameter to a WebGetAttribute or WebInvokeAttribute. Here is an example of the latter:
[OperationContract]
[WebGet(UriTemplate="/products?index={index}&pageSize=
{pageSize}")]
WineData GetProducts(int index, int pageSize);
* One important thing to note. In the current release (SP1), if your variables are part of the query, such as above, we will do simple type conversions for you. So, in the previous example, note that GetProducts takes in integers, but clearly the querystring parameters are strings. We will take care of this simple conversion for you. However, if the variables are in the path, we will not. There is no reason for this, other than it was done for the query, not the path. It is my understanding that support for type conversions in the path is on the list for a future release. Just thought you might like to know.
As you can see, the UriTemplate is useful in controlling the URI. However, there are limitations. As my might have noticed, the template is defined for the path and querystring after the path to the svc file. It does not provide any help for manipulating that portion of the URI.
(see this article on MSDN for more information on UriTemplates)
Given this information, we could define a UriTemplate to clean up the URI for our GetWine operation. Perhaps we want the path to be something like this: wine/17 (where 17 is an actual wine id). We could simply change our code to look like this:
[OperationContract]
[WebGet(UriTemplate="wine/{wineID}",
ResponseFormat = WebMessageFormat.Xml)]
WineData GetWine(string wineID);
The call would look like this:
UriTemplate Enhancements in WCF 3.5 SP1
The WCF team added some enhancements to UriTemplates when Visual Studio 2008 SP1 (and Fx 3.5 SP1) was released. These included support for default values for parameters in paths and compound template segments. It is simple to define a default value. Simply set the variable to the default value with an ‘=’. Remember that you cannot assign defaults to variables in the query portion of the template. Here is what our example would look like, setting the default value of wineID = 22:
[OperationContract]
[WebGet(UriTemplate="wine/{wineID=22}",
ResponseFormat = WebMessageFormat.Xml)]
WineData GetWine(string wineID);
You can now omit the id segment of the URI like this:
Compound template segments allow you to combine both variables and literals within one segment. If you are familiar with ADO.NET Data Services, you will note that the ID for entities uses compound template segments. The IDs look like this: Entity(id). ADO.NET Data Services runs on WCF and the webHttpBinding, so you might rightly assume that this functionality was added for this purpose. However, you can take advantage as well. If I wanted to implement a similar ID scheme, it would look like this:
[OperationContract]
[WebGet(UriTemplate="wine({wineID})", ResponseFormat =
WebMessageFormat.Xml)]
WineData GetWine(string wineID);
Here is what it looks like:
Completely Controlling the URI
All of the examples we have seen so far only allow us to template the URI after the path to the svc file. If you want to take full control of the URI, you have to do some kind of URL Rewriting. There are a variety of means to accomplish this. ScottGu’s blog post Tip/Trick: Url Rewriting with ASP.NET illustrates 4 approaches, including implementing HttpModules, using Request.PathInfo and taking advantage of 3rd party ISAPI filters. John Flanders’ blog post Using WCF WebHttpBinding and WebGet with nicer Urls illustrates how you can build an HttpModule with IIS7 for URL Rewriting. In this post, I will illustrate how you can take advantage of the new URL Rewrite Module for IIS 7.0 CTP1. This module allows you to simply add rules that define pattern matches (either Regular Expressions or WildCards) and rewrite to a specified URL pattern. Actually the module does more than that. To see the full functionality, check out Bill Staples’ blog post on the subject.
For our purposes, we simply want to define a pattern for the incoming URL using Regular Expressions. This pattern will represent what we want the "Hackable" URI to look like. We will then take this URI and rewrite it to the actual path that we defined earlier ([protocol]://[hostname][:port][/path][/svc filename]). An example will probably best illustrate our goal and how we can accomplish it. Taking the last example we had, the URI looked like this:
As my annotations clearly point out, we may not want the ".svc" as part of our URI. That is really a technical implementation detail and does not really have a place in the "hackable" URI. So, for this simple example I will illustrate how we can use the Url Rewrite Module to remove the svc extension. Here is the process:
You are ready to go. But before we test it, I want to dissect the pattern we used for matching. The match pattern was:
^([0-9a-zA-Z\-]+)/([0-9a-zA-Z\-\.\/\(\)]+)
Here is the breakdown of the pattern:
The rewrite URL is simply everything in the first named capture group (everything prior to the first /) which should be the svc file, without the svc extension. We then append an svc extension and a slash. We then append everything in the named capture group.
Let’s see it in action. Here is our new svc-less request:
Eliminating the ".svc" extension is just the tip of the iceburg. Hopefully, you can see how you can take full control of the URI.
Jean-Paul Smit has released a new version of Biztalk Solution Factory now with support for generating unit tests. The unit test support is based on BizUnit 2.2 and NUnit 2.4.7. There are actions for generating schema tests, map tests and orchestration tests. Check it out…
As you know “Oslo” is the family of new technologies that enable data-driven development and execution of services and applications. There will be several sessions at PDC discussing the technologies involved in “Oslo” in much detail. In the interim, we have published two interviews on Channel 9.
In these interviews, our very own Ron Jacobs talks to David Chappell and Jon Flanders to understand their perspectives on “Oslo” and how we can prepare for the road ahead. If you’re wondering about “Oslo” tools, language and repository and want to build your apps today to prepare for the road ahead, you’d then definitely want to watch these videos.
Enjoy!
Marjan Kalantar