April 2008 - Posts

• Free Windows 2003 Server Hosting

  Host your own Windows 2003 Server with SQL Server FREE! How does it work? Just use my services for a minimum of 10 hours per calendar month! Get a Windows 2003 Server with SQL Server 2005 hosted free for 30 days when you buy 10 prepaid hours of consulting time (payable via PayPal). Specifications: Windows 2003 Server  SQL Server 2005 Express Up to 200Gb data transfer 30 days of hosting Static (non-changing) IP address The server includes IIS (Web Server including ASP.NET) and 1Gb of memory, and 60Gb of total disk space. Other configurations are also available, including SQL Server 2005 Standard. Contact me for details (click the Contact link or call +1 416-809-1453). Posted Apr 30 2008, 07:27 PM by Erik with no comments Filed under: Services

• Commentary: Services Strategy

  In a new paper, Microsoft's Chief Software Architect, Ray Ozzie suggests that Content, Community, Commerce, Search, and Advertising are strategic areas for investment (download PDF / read online). The paper, called Services Strategy, is being marketed under the Saas/S + S/ Software as a Service banner. SaaS is an approach that delivers applications, APIs, and services (like email) to end users via the Internet. In an SaaS model, users and organizations only need to concern themselves with two things: using the applications or services and making sure their Internet connection is up. The SaaS delivery model handles important aspects of application management including hosting, security, scaling, virus scans, reliability (hardware maintenance), and of course software updates/deployments. The Saas/S+S/Software as a Service marketing spin is misplaced. Ozzie's paper starts out strong with an overview of what begins as the 3 C's (content, community, and commerce), and ends up as the 3 C's plus search and advertising by the end of the first page. The rest of the five page memo quickly spirals into an infomercial for Microsoft's new Mesh platform and finally ends with an overview of things to come (Mesh centralizes the management of devices like your computer and phone and makes applications seamless across those devices). SaaS goes beyond hosing data and putting a nice looking interface infront of it. SaaS part of an overall strategy to build and use composite applications. A composite application made up of other applications and services and adds value though not only code, but also services like support, marketing, and strategic planning. More about SaaS soon! Posted Apr 24 2008, 10:29 PM by Erik with no comments Filed under: Op-Ed

• BizTalk and UDDI -- Finally in BTS 2006 R3

  BizTalk 2006 R3 - Microsoft's next release - is expected to more closely align with Windows Server, SQL Server, the .NET Framework, and Visual Studio. Thats' great - the best part is support for UDDI 3.0! I have been an advocate of UDDI in several projects, so it is nice to come back into mainstream use. UDDI is perfect for SOA and ESB-style applications since it makes service discovery much easier. You can query a UDDI server for services based on attributes like business category, location, performance - basically whatever makes sense for your design or organization. Service discovery is an integral part of a robust solution since you can bind to services at run time based on your requirements at the time, roll over to another service when the primary one is not available, and extend services available to existing applications without having to rewrite them (assuming the contract among services is the same). I think Microsoft is doing a great job of listening to its customers - it is time, though, to make products like BizTalk more accessable to smaller organizations, service providers, and other small to medium size businesses through adjustments in the licence pricing. Posted Apr 23 2008, 09:50 PM by Erik with no comments Filed under: BizTalk

• Consuming Asynchronous Web Services Using ASP.NET

  Most integration solutions include Web Services somewhere in the overall solution. The Web Services could be internal, that is, within the organization's network or external - provided by another party. BizTalk Orchestrations can be published/exposed as Web Services. This post is about Web Service consumers - specifically ASP.NET consumers. A project I worked on included an ASP.NET solution that called out to various Web Services. The Web Services often ran for a long time thereby blocking the ASP.NET thread which, of course, gives the user the impression that nothing is happening. When you call a Web Service from an ASP.NET page, you do that as the result of some event - button clicks are the most common. When the user clicks  a button, the user is essentially posting the page back to IIS so that the code in or behind your page can execute. The problem begins here because the only time you can handle events is on post back. If you happen to call a Web Service before the page renders, rendering stops until the call to the web service completes or times-out. The user is left staring at an empty browser until something happens. This is nothing new, but there has to be a better way. The idea behind blocking a page's thread until a web service call completes is logical: most calls to web services are synchronous and there is no way ASP.NET can know if any parts of the page it is about to render depend on the result of calling into the web service. Given ASP.NET's simple programming model, the only choice is to block rendering until the call completes or times out. ASP.NET 1.0 used a begin/end paradigm that used IAsynchResult to extract the  result of the web method call. This approach needed a new thread to invoke the call. Most ASP.NET 1.0 implementations use ThreadPool.QueueIserWorkItem, Thread.Start, and asynchronous delegates (events). Threads from the Thread* methods used threads from the ASP.NET thread pool which became starved of resources under load (since there are a finite number of ASP.NET threads per processor). While this model was good, it had its problems and made developing web pages that use asynchronous communications more difficult. ASP.NET 2.0 attempts to simplify the asynchronous processing model by integrating many operations directly into the 2.0 implementation. While the implementation is good for many cases, it does not address fine-grained management of page's lifetime (and, by association, the thread that runs the page). The ASP.NET 2.0 page model makes asynchronous calls easier using an event driven model. When a developer wants to have a page asynchronously call a web method, she must mark the page as asynchronous. Doing this basically prevents the page from rendering until the asynchronous method call completes- which is bad for the user but very easy for the developer. If an error occurs the developer could render an Error page, otherwise the developer could render a page that displays the result of the method call. Back to square one I suppose. Ideally, it should be possible to call a web service on post back without having to render the page. The good news is that this is possible. The bad news: it does not work well. You need a short history lesson to understand what is happening today: Microsoft introduced a novel asynchronous programming model with the release of IE 5.0 (released in early 1999). The IE 5.0 model pushes asynchronous operations into IE so that all ASP.NET had to do was render the page, and then let IE invoke web methods on its own and fill in the page with the results. While this model works very well, it had security and deployment related problems (it works only with IE 5.0 or later). Back to today, ASP.NET 2.0 broadens the reach to other browsers and still basically requires that the browser invoke the web method asynchronously. The difference is that some client code notifies the ASP.NET code when asynchronous web methods complete. The code in the browser is responsible for managing the data on the page and takes a very rudimentary approach to transporting data between the browser and ASP.NET. The revised version also improves thread management by basically spreading out processing between client and server and establishes logical thread affinity on the server (since everything is basically synchronous as far as the developer is concerned). The key part of that last paragraph is: The code in the browser is responsible for managing the data on the page and takes a very rudimentary approach to transporting data between the browser and ASP.NET. Rudimentary is really the only way to describe it, unfortunately. The browser just sends back a string containing whatever data it captures (reference). The samples available on MSDN demonstrate a couple of approaches; however, they are simple in terms of how they manage data. More complex solutions are likely to have to parse through a delimited string - so you end up going backwards - way back - just to get some asynchronous behaviour. The lack of support for moving data between the browser and ASP.NET forces developers to question the value of asynchronous web service calls in terms of not only implementation, but also testing and post-deployment maintenance. In the end, many opt for maintaining the status quo. Posted Apr 18 2008, 04:09 PM by Erik with no comments Filed under: ASP.NET

• Microsoft Announces BizTalk RFID Mobile

  "Microsoft BizTalk RFID Mobile when used with BizTalk Server 2006 R2 enables real-time decisions by extending business process to Windows CE and Windows Mobile 5.0 applications". Link to the press release. While this could help boost BizTalk's precence in the marketplace, I think one of the main factors that slows down the adoption of BizTalk is the licencing fees. The cost of the licence makes it difficult to justify BizTalk for smaller organizations and startups. While developer licencing makes the product accessible to a lot of developers, the regular licence fee - even for hosted solutions - and when combined with SQL Server quickly pushes it out of reach. Posted Apr 18 2008, 02:54 PM by Erik with no comments Filed under: BizTalk

• Understanding BizTalk's Extensibility

  BizTalk's programming model is largely based on orchestrations that, when used in combination with maps, for example, usually provides enough functionality for a range of problems. There can be cases when it is either difficult* or not possible* to represent a solution using BizTalk's stock toolset. BizTalk developers can extend BizTalk functionality using C#, Visual Basic .NET, or any .NET-supported language. You package your code in an assembly (DLL), or Class Library project in Visual Studio .NET and reference it from your BizTalk project in Visual Studio like you reference any other assembly (Select Project -> Add Reference from the Visual Studio menu). You can access your assembly's functionality using an Expression shape from the Orchestration designer toolbox. On hearing the great news, most developers fire-up Visual Studio and happily start writing a bunch of code (after all, BizTalk uses a declarative approach. If you like code it is hard to resist an opportunity to be in control again by writing your own code). Before you do that, make sure that you really cannot express your proposed solution in BizTalk. Project Reviews, Architectural Guidance, Design Reviews, New Staff/Candidate Reviews Contact Erik Westermann for more information (+1 416-809-1453). When I was learning C++ I got stuck on several problems along the way. I often found myself late at night sitting in front of my noisy 486-based system - its 200Mb hard drive spinning the bits of my solution at the same dizzying rate that I was going through ideas to try to solve my problems. On further reflection about the problem at hand I found that I was standing in my own way - I was not able to find solutions to the problems because my approach was wrong. I ignored the symptom (not being able to solve the problem) and instead focused on finding a solution. I easily came up with an effective solution the moment I changed the way I thought about the problem! My point is that I see a lot of developers immediately creating new assemblies, writing a bunch of code, and then calling that code through BizTalk. The presence of the code is often a symptom of not understanding the problem, understanding BizTalk, or both. You need to keep this in mind if you still need to write some code: All of the types you use in your code must be serializable. An example of an object that you cannot serialize is SqlConnection. You must sign your assembly and deploy it into the GAC (Global Assembly Cache) to be able to call it from your BizTalk solution. Since your assembly is in the GAC, you may have to think differently about using configuration values from a config file. These points are not as bad as they seem. I'll address the first two and leave the last one for you to figure out for your homework. SOA / BPM / ESB / SaaS / S+S Forget the alphabet soup - you'll get the main course with our consulting services! Contact Erik Westermann for more information (+1 416-809-1453). The first point, about using serializable types, is easy to address: avoid using non-serializable objects! The great thing is that this is pretty easy to do since most types you use day-to-day are in fact serializable. If you accidentally use a serilaizable type, or cannot avoid using one* you might be tempted to use some unconventenial approaches. For example, if you look around the internet you might find some interesting ways to work around this by tricking the type system into serializing a non-serializable type - use those techniques with extreme caution. You have to mark your types (classes) serializable for BizTalk to accept them - just add the [Serializable] to your class' declaration. The compiler will gently remind you with a cryptic error message if you lie and use non-serializable types anyway. The second point - you need to sign your assembly and deploy in the GAC - is also really easy to address. Signing in this sense is actually to Strong Name-ing your assembly. You can use the Strong Name Utility (sn.exe) or use Visual Studio to sign your assembly. Deploying the signed assembly is also easy: just drag the assembly to the c:\windows\assembly folder (it goes there as a copy), or command line enthusiasts - use can use gacutil (gactul.exe). Note that I will say that I have oversimplified the management aspect of strong naming and deploying assemblies into the GAC. Those topics are out of the scope of this particular article. Let me know if you'd like to see an article about that. The great feature of both of these points this is that these procedures build on your knowledge of the .NET Framework, so there is not much more for you to learn if you are already familiar with these tasks. If you are not familiar with these tasks, then you'll gain a deeper understanding of the .NET Framework. Thinking about or already using Commerce Server 2007? Integrate your CS 2007 solution with CRM, Payment gateways and more! Contact Erik Westermann for more information (+1 416-809-1453). Although you can do just about anything you like in your custom assembly, you should carefully consider the performance impact of your code. For example, loading a huge XML document into an XmlDocument object will use a lot of memory, which can slow overall performance due to paging. I personally like to keep my custom code as lean as I can: I use StringBuilder, streaming types, I try to use math whenever I can, and use compact representations of data even if that makes my code a little more complicated. The classic rule still applies - avoid optimizing too early and without knowing whether it is necessary; however, if you know that you are processing very large messages then it makes sense to avoid operating on them entirely in memory. * - When something seems impossible, it is usually a symptom of incorrectly approaching the solution or having an incomplete understanding of the problem (or both, at worst). You can more effectively address the solution when you understand BizTalk's capabilities - I am happy to say that I have not yet come across a problem I could not solve using BizTalk. Gaining a complete understanding of the problem is an exercise I'll leave to the reader. Posted Apr 11 2008, 10:04 PM by Erik with 1 comment(s) Filed under: BizTalk

• Series on Getting to Know BizTalk

  The sum of the individual parts is indeed greater than the whole... I am working on another part of the series of articles about getting to know BizTalk. The series got its start when I completed writing a larger article for another internet publication. The article went through a few rounds of editing when the project came to a grinding halt. The publication was looking for volunteer authors and I suppose that the editors got busy with other things.  I looked at the article again and started to revise it when I broke it into smaller sections. The result is what you see here. I plan to roll all of the parts I publish here back into a larger article and publish that on CodeProject.com. There will be more articles too - on looking through my server logs I found some interesting search queries which gave me some ideas. I am always interested in hearing from you. Would you like to see something covered in an article about BizTalk? Contact me by clicking the Contact link or send an email to me at erik [dot] westermann [ at ] gmail[dot] com (I have no idea if that thwarts email address harvesters...but it is worth a try. If it does not work, Google's fantastic spam filter will catch any junk email). Posted Apr 09 2008, 03:02 AM by Erik with no comments Filed under: writing, BizTalk

• BizTalk: Understanding the Publish-Subscribe Model

  Note: Screencast available! The screencast demonstrates publish-subscribe - click to view the article and video! BizTalk is, at its core, a messaging system that is based on a model called publish-subscribe. The publish-subscribe model is an asynchronous programming technique that makes it easier to share information between entities that send information (publishers) and entities that receive information (subscribers). The main advantages of the publish-subscribe model include scalability (the ability to take advantage of available, changing, resources) and flexibility (works as the basis for many other programming approaches). In more concrete terms, think of publish-subscribe as if you are a speaker at a conference. You publish information using your voice and the audience is consuming that information by listening. You are actively publishing information and members of the audience register their interest by being present and listening. You can speak to an audience of one person or hundreds - the only difference is in how you project that information (speaking plainly, loudly, or using a microphone). The way you project the information is the one aspect of scalability - you can reach more members of the audience over a larger physical space with resources like a microphone and a small speaker or several large speakers. Your speech (content) is the same if the audience has one person or hundreds. Audience members can leave and new members can join at any time without affecting your ability to publish information. Since people can join or leave at anytime, you are effectively decoupled from not only the overall audience, but also, the identity of the individual members of the audience - you are essentially making a speech to anonymous members of the public. Project Reviews, Architectural Guidance, Design Reviews, New Staff/Candidate Reviews Contact Erik Westermann for more information (+1 416-809-1453). BizTalk handles messages in the same way: BizTalk publishes messages to a common area and processes that are interested in consuming the published messages subscribe to them (orchestrations, receive or send ports, or directly bound ports). The publish-subscribe model wouldn't work if all subscribers receive all messages. When a subscriber registers its interest, the registration includes filters to select messages of interest. In general, there are two types of filters - topic based filters that BizTalk represents as Receive Ports or Send Ports, and content based filters which filter messages based on their content - BizTalk provides several means of filtering based on content. So what does a BizTalk subscription look like? Here is an example: http://schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortID == {E2CAB447-6BB0-4C51-ABB2-8F02A19A8837} And http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == http://example.com/sample#Person The subscription includes both types of filters that I mentioned earlier: The topic filter is based on the ReceivePortID The content filter is based on an attribute called MessageType A Receive Port is an abstraction (logical representation) of a means to receive a message using a specific protocol or location. For example, BizTalk can receive messages in files, from Message Queues, or via HTTP (among the methods - there are others). The specific protocols and locations are referred to as Receive Locations. There can be several Receive Locations per Receive Port making it possible to accept messages from a variety of locations and treat them the same way in BizTalk. The following is how BizTalk represents a Receive Port in the Orchestration Designer: The MessageType is a representation of a message's type. BizTalk represents all messages in XML. One important aspect of all XML documents is its namespace. Briefly, a namespace allows you to describe a Person (for example) in one way without affecting anyone else's description - since Person can mean different things to other applications. Another important aspect of all XML documents is the name of the document's root node. In the preceding example, the combination of the message's namespace and name of the root node are represented as: http://example.com/sample#Person The hash symbol (#) separates the namespace from the name of the root node. I'll explain more about the concepts of XML namespaces and root node names in a future blog post. Project plans, work estimates / Prototypes and Proof-of Concepts Get expert consulting without the huge commitment of multi-year contracts. Get fast, effective, and accurate answers! Contact Erik Westermann today for more information (+1 416-809-1453). So where is the "Publish" part of publish-subscribe? You can publish messages in BizTalk in a variety of ways including: Sending a message to a receive port Calling an orchestration from another orchestration Creating a direct bound port (more about this in a future blog post) Publishing messages for which there are no subscribers (known as routing failures) BizTalk is very robust since it can recover from a variety of hardware and software failures. This robustness is provided in large part by SQL Server - BizTalk's message and configuration store. BizTalk not only manages publications and subscriptions using SQL Server, it also uses SQL Server to store and route messages. The logical name of the common location where publications and subscriptions take place is called the MessageBox - a BizTalk SQL Server database. If you think this article is good - imagine what we can do for you! Contact Erik Westermann for more information (+1 416-809-1453). The MessageBox is an integral part of BizTalk's implementation; however, it is not strictly necessary, as a developer, to know much more about it than the fact that it exists and its role. The BizTalk system (Visual Studio and the management tools) abstract the MessageBox database so you can treat it as an opaque, supporting, subsystem, I welcome your feedback - comment on this article or use the Contact link to send an email directly to me! Posted Apr 01 2008, 05:40 PM by Erik with 2 comment(s) Filed under: BizTalk