by Thomas | Dec 11, 2006 | BizTalk, Microsoft
You’re already familiar with the Microsoft Management Console (MMC) if you’ve ever opened Computer Management, IIS Administration or any of the other Windows management tools. The most common version today is 2.0, found on Windows Server 2003 and Windows XP. Back in March 2006, Microsoft released MMC 3.0 without much fanfare. The big changes in 3.0 are a new programming model for .NET-based snap-ins and reliability improvements. MMC 3.0 can isolate snap-ins from each other, at least if they are .NET-based, and do a bit better job of error handling and logging in general.
If you have not already installed MMC 3.0, you’ll need it before too long. BizTalk Server 2006’s Enterprise Single Sign On Admin tool requires MMC 3.0, and there will be many more in the future.
There are freely available versions of MMC 3.0 for the various editions of Windows, but you need to get the right one for your OS. Search Microsoft Downloads for ‘MMC 3.0’ to find the one you need. You’ll need Windows XP SP2 or later, or Windows Server 2003 SP1 or later. If you’re running Vista, you can stop reading now, because you already have MMC 3.0 and it is pre-optimized!
Once you have MMC 3.0 installed, you may find that snap-ins that rely on it (and you generally won’t know which ones do) start up slowly. You may find yourself staring at the screen for a long time each and every time you start up one of those snap-ins. The reason is that a bunch of code in MMC 3.0 is written in .NET. No, that in itself does not make it slow! For some unknown reason, Microsoft does not optimize the MMC 3.0 .NET code upon installation as it does with the .NET Framework itself. (For you developers, the DLLs aren’t automatically GAC’d, nor are native images generated.)
There’s a very easy fix for this. Speed up your MMC 3.0 snap-in startup times by opening a Command Prompt and running ‘mmcperf.exe’. It’s in your Windows\System32 directory. This will create ready-to-run versions of the MMC .NET code (native images). You’ll notice a big difference in startup time — and we may never know why Microsoft didn’t just do this out of the box! Note that this does not speed up the snap-ins once they are actually running. This is related only to the startup time when you run MMC and load a .NET-based snap-in.
Like this:
Like Loading...
by Thomas | Dec 7, 2006 | Development
I frequently hear comments that Web services are inappropriate for carrying large data messages, say greater than 1 MB. In the past there was some truth to that, but no longer. There is really no reason to avoid a Web service simply because you have to send or receive a bunch of data.
By default, transferring non-ASCII data over a SOAP call means using Base64 encoding. You have to go back to the early days of the Internet to find the Base64 definition in IETF RFC 1521, which was adapted from an even earlier RFC. Base64 typically increases the size of the encoded data by 33%, not to mention the CPU and memory required to encode and decode. Imagine sending a 3 MB PDF over a SOAP call with Base64 encoding. That PDF gets translated into a 4 MB ASCII string, transmitted to the other endpoint, and then converted back to the original 3 MB PDF. Clearly this is not an efficient scheme.
Years ago, Microsoft first addressed this issue in the Web Services Enhancements (WSE) add-on to .NET with their proprietary DIME extension to SOAP. Like MIME, DIME is designed to define message attachments of varying data types, but in this case to a SOAP message. According to Microsoft, DIME was a more efficient format than MIME for message parsers. It was not widely adopted.
Why attachments? Just like sending an email, you might want to send a SOAP message that carries alongside it one or more other chunks of data, whether that’s a ZIP file, another XML file, a PDF, etc. An attachment scheme like MIME defines in the message header the list of attachments, and for each attachment an encoding method. We would prefer to use a binary encoding method that does not increase the size of our data.
The W3C standards organization got involved with the advent of the Message Transmission Optimization Mechanism (MTOM), which today is a W3C Recommendation. MTOM uses concepts from MIME/Multipart to add attachments to a SOAP message, and it can optimize elements of type base64Binary. If you put data into a base64Binary element with MTOM disabled, you will literally see a Base64-encoded version of your data (and much bigger than the original). If you look at the same element with MTOM enabled, you will find a pointer to a MIME part that contains your actual data in binary format.
MTOM is available today for .NET 2.0 Web services in Web Services Enhancements (WSE) 3.0 and Windows Communication Foundation. Both of these are freely available and fairly easy to use. WSE 3.0 is perfect for your existing ASMX Web services because there is usually no code to change to take advantage of MTOM. Keep in mind that clients of an MTOM Web service also need to be MTOM-aware. The only requirement is that the data element you wish to optimize is of type base64Binary in the XML, and a byte array in your .NET code. Once you enable WSE3 on your Web service project, you can simply enable MTOM in the WSE configuration. Remember to enable it on the client side too.
Attached to this post you will find a sample .NET 2.0 solution that demonstrates a single Web service implemented in plain ASMX, ASMX with WSE3 and WCF. You’ll notice that there is no special code at all for MTOM, just configuration. If you use an HTTP monitor like Fiddler to examine the SOAP messages, you will see the differences with and without MTOM.
It is worth pointing out that BizTalk 2006 Web services CAN take advantage of MTOM! When you publish a schema or orchestration as a Web service, what comes out is a regular old .NET 2.0 ASMX Web service. Again, as long as the large data elements are defined as type base64Binary and as a byte array in code, MTOM can be enabled with no code changes. Just update the BizTalk Web service project to enable WSE3 and MTOM.
Please contact me if you have questions, and please take advantage of these free and easy tools to make your Web services faster.
webservicesmtomdemo.zip
Like this:
Like Loading...
by Thomas | Dec 1, 2006 | BizTalk
BizTalk Server has long been one of the most powerful — and unwieldy — tools in Microsoft’s server arsenal. Sadly, BizTalk 2006 is what BizTalk 2004 should have been, and one wonders why it took so long to arrive. Frankly, I’m not sure that Microsoft really knows what to do with BizTalk. I believe that the product is misunderstood even within Microsoft itself, and I do not think the marketing and sales teams really know how to market and sell it. When you consider the number of years that BizTalk has existed (six), it has a very small number of customers.
Developers naturally want to write custom code, so it’s not easy to convince them of BizTalk’s benefits. It certainly doesn’t help when Windows Workflow (WF) comes along with a big marketing bang and further distracts the developer community. Now you’ve got developers looking at the WF design surface and thinking that it looks just like BizTalk’s, so it must be the same, and it must be better because it’s newer. True or not, this is the kind of problem that Microsoft has created for itself.
I believe that Microsoft needs a different approach to selling BizTalk. First of all, the product group needs to get a grip on the product’s future direction, and then educate — repeatedly! — Microsoft’s sales teams until they finally understand the product and how to sell it. Second, pushing feature lists is a lost cause. Your average CIO/CTO doesn’t care. Microsoft should be selling BizTalk with specific business scenarios. They could build example solutions that are written in both C# and in BizTalk, and show explicitly how BizTalk reduces code, brings in management and monitoring features, etc. Reducing the barrier to entry is critical. Providing extensive samples and prescriptive guidance for developers would help adoption from the technical side.
Here’s my list of the top three issues in BizTalk 2006 that the product group should address in v.Next:
Inadequate support for medium to large sized messages. In an ideal world all messages would be 0-150KB, but realistically people need to send around metadata plus documents like PDFs, etc. The larger the message size the quicker problems are encountered, from hosts running out of memory and crashing to high CPU utilization to extreme SQL Server stress.
BAM is extremely valuable but still too hard to configure, so it is not used as often as it should be, and that is really a shame. The tools need to be brought together into the Visual Studio IDE or into the Admin Console.
Debugging tools are not even CLOSE to Microsoft standards. Visual Studio is known for an outstanding debugging experience, and BizTalk has a horrible debugging experience. We should be able to open a BizTalk project and directly debug pipelines and orchestrations in the IDE.
What else should the product team improve upon? How could Microsoft better position BizTalk in the market? I’d love to hear your opinions.
Like this:
Like Loading...
by Thomas | Oct 18, 2006 | General, Microsoft
Starting a couple of days ago I was suddenly unable to sign into Windows Live Messenger. The signin graphic would just spin endlessly, or I’d get a “service not available” message.
In case you have also run into this (many have), Microsoft did a bad thing (supposedly now fixed), and the effect is that bad data may have been cached on your PC, which prevents you from being able to log in.
Here’s some info on the problem.
The solution if you are using Windows Live Messenger 8.0.x is to delete the registry key HKCU\Software\Microsoft\MSNMessenger\Policies. As always, don’t attempt this if you are not comfortable editing the Windows registry.
Another related issue they describe is specific to ZoneAlarm firewall users, and that one is pending a fix as of this writing. They suggest dropping back to an older version of Messenger until that fix is available, so hopefully the registry key will fix it for you.
Like this:
Like Loading...
by Thomas | Oct 9, 2006 | BizTalk
Thanks again to everyone who attended my session entitled “Effective Techniques for Handling Large Messages in Service Oriented Solutions” at the Microsoft SOA & BP Conference. The session covered the difficulties of working with large messages in service-oriented environments, then provided general strategies and specific guidance for both BizTalk Server 2006 and ASP.NET Web services.
Here’s the PowerPoint presentation from the session. I’m still debating how to release the Slice/Splice BizTalk pipeline component code. One option is to create a new community project at either CodePlex or GotDotNet. Another option is to use a GPL or similar open-source license. Any ideas? Please let me know what you think.
soa04_abraham.zip
Like this:
Like Loading...
by Thomas | Oct 6, 2006 | BizTalk, Personal
It’s the last day of the Microsoft SOA & Business Process Conference and just about time to head for home. I’ve had a great week in Redmond and have had a chance to talk with many other members of the BizTalk community. The conference has more than 700 attendees, and I was surprised to discover that 40% or more were international. QuickLearn has been running some great training classes on BizTalk, WCF, WF and Atlas both before and after the conference.
Thanks to everyone who attended my session on working with large messages in BizTalk and ASP.NET Web services! The session was well attended and, not surprisingly, a lot of people are having these issues. As soon as I get approval from Microsoft, I’ll get a post together with the PowerPoint slides and the pipeline component code.
Overall, the conference was worthwhile, but I would have preferred much more detail in the sessions and greater presence from the MS product developers. Hopefully that will be improved for next year. No real news from the conference other than the limited availability to partners of an ESB guidance package for BizTalk.
Thanks for reading and please stay tuned for the session materials.
Like this:
Like Loading...
by Thomas | Aug 22, 2006 | Development
You might have used the VB6 to VB.NET Upgrade Wizard in Visual Studio, or maybe the Java Language Conversion Assistant (JLCA) to convert Java code to C#. These tools have something in common – the technology comes not from Microsoft, but from a company called ArtinSoft.
This is a company with some very intriguing products based on artificial intelligence engines. Their business is all about source code and platform conversion – VB6 to VB.NET, Java to C#, PL/SQL to T/SQL, Linc to J2EE – you name it, they can probably do it. They have two AI-based engines, and the one called Freedom is behind JLCA and the VB.NET Upgrade Wizard. Through a complex process, this engine creates a langage-agnostic intermediate representation of the original source code, which can then be written out in a completely different language.
Now, people tend to complain a lot about the VB.NET Upgrade Wizard, but if you stop and think about what the tool has to do, it works incredibly well. The quality of the original source is obviously going to be a major factor. If the VB6 source has Option Explicit off and looks, well, like most VB6 code does, it’s amazing that the wizard can make any sense of it.
One important thing to know is that ArtinSoft sells their own versions of both of these tools: the Visual Basic Upgrade Companion and the JLCA Companion. These products are much more advanced versions of the free tools. The VB Upgrade Companion can even convert your VB6 code to C#. Yes, VB6 directly to C#! How cool is that? ArtinSoft also offers consulting services to help with your migration projects.
Sometimes the right answer is to redesign and rewrite your code. Other (most?) times, that is very hard to justify to your CIO, and that’s when your company might want to consider ArtinSoft’s paid applications and services. Cost may still be an issue, since I hear that these tools are licensed by number of lines of source code, but that’s something to evaluate while you look at all of the pros and cons and make a final rewrite/upgrade decision.
Like this:
Like Loading...
by Thomas | Aug 22, 2006 | BizTalk, Personal
The Microsoft SOA & Business Process Conference is coming soon. This is a great 4-day conference held at the Microsoft campus at an awesome price – only $199! Consider that TechEd costs nearly $2,000! Of course you have to pay to get there, but really, this is still a terrific deal.
The conference features four tracks, three technical and one business:
- Service Oriented Architecture (incl. BizTalk 2006, WCF, WF, HIS and more)
- Connected Systems Technology and Products (.NET 3.0 and BizTalk 2006)
- Business Process Management (Office System 2007 and BizTalk 2006 R2)
- Business Value (Why care and what are the opportunities)
The agenda and sessions are still being finalized, so keep checking the conference website for updates.
I’m pleased to announce that I will be presenting the following session in the SOA track, so I hope to see you there!
Effective Techniques for Working with Large Messages in a Service-Oriented Architecture
In a Service-Oriented Architecture (SOA), small messages are easy to work with and don’t create extra challenges of their own, but various issues arise when the message size grows to megabytes in size. This session will identify the issues you should consider and then explore specific techniques that you can use to work effectively with large messages in ASP.NET 2.0 Web services and BizTalk Server 2006.
Like this:
Like Loading...
by Thomas | Aug 3, 2006 | Development, Microsoft
One of the coolest resources that Microsoft employees have is an internal website filled with hundreds and hundreds of small but useful apps and utilities, many of which were written by Microsoft employees. Sadly, few of the tools are made available outside of Microsoft, but here are a bunch that have made it out and places to look for more.
Fiddler: In the author’s own words: “Fiddler is a HTTP Debugging Proxy which logs all HTTP traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP Traffic, set breakpoints, and “fiddle” with incoming or outgoing data. Fiddler is designed to be much simpler than using NetMon or Achilles, and includes a simple but powerful JScript.NET event-based scripting subsystem.”
Sandcastle: This is the actual tool that Microsoft uses to generate the .NET Framework’s MSDN-style documentation. NDoc works fairly well, but Sandcastle is the new tool of choice for building help files.
FxCop: The same tool behind “Code Analysis” functionality in select Visual Studio 2005 Editions, this is one of the most important tools for .NET software developers. This outstanding tool analyzes managed code assemblies for over 200 types of defects, and will point out all kinds of “gotchas” that you never would have noticed on your own.
LogParser: A truly amazing tool, LogParser allows you to write SQL queries against data stored in random files in all kinds of different formats, including XML, CSV and various IIS log formats, and it can write the results to lots of different formats — all without loading the data into a database! If it doesn’t support the format you need, you can write an extension for it.
WiX: One of the first, if not the first, internal Microsoft tool to go open-source. A set of command-line utilities that build MSI/MSM files from XML command files. Great for building installers in an automated build process.
RoboCopy and much more: RoboCopy is a very powerful and reliable file copy/move tool that also includes directory synchronization. It is packaged with dozens of other great tools in the Windows Server 2003 Resource Kit Tools package. (Many of the tools do not require Windows Server 2003.)
One of the newest and fastest-growing places to find Microsoft-created tools is CodePlex, Microsoft’s newest “community development” website. There is no good way to determine exactly which projects originate from Microsoft, but some are clearly stated. One of the tools you will find here is the Team Foundation Server Administration Tool.
Some tools turn up on the official Microsoft website as unsupported downloads. For example, Lookout, released in early 2005, is an Outlook add-in that lets you quickly search all types of Outlook and file system data. Not very useful, perhaps, in this age of Windows Desktop Search and Google Desktop, but it’s an example of what you can find if you dig around in Microsoft Downloads.
Browse the GotDotNet User Samples area — look for the Microsoft logo next to the sample title. XML tools and Web Service tools are also available on GotDotNet.
Know of more useful tools that originated inside Microsoft? Please share them!
Like this:
Like Loading...
by Thomas | Jul 24, 2006 | BizTalk, Personal
I’ve been doing my best to procrastinate taking all of these certification exams, so I finally had to just schedule and go, ready or not. So, a week after the 70-536 .NET exam and feeling a bit rusty with BizTalk 2004, I took 74-135, the BizTalk Server 2004 TS exam. Passing is 700, there are 40 questions and you have two hours max.
Fresh hands-on experience definitely helps with this test, as well as a lot of facts and useless knowledge like the command-line parameters to the management tools. Microsoft’s expert test writers seem to believe that one will not have access to the product documentation to simply LOOK UP command-line parameters!
Having not laid a hand on BizTalk (2004) for at least three months, and having procrastinated studying again, I wasn’t looking forward to test day, but I passed and it’s done, so it was worth the trouble.
So how did I prepare (or not, in this case)? I read the first 300 pages of BizTalk 2004 Unleashed in the three evenings prior as a refresher. Beyond that I relied on my brief experience of 6-8 weeks earlier this year developing with BizTalk messaging and orchestrations, and I have done many BizTalk installs with both 2004 and 2006, not to mention debugging other peoples’ BizTalk solutions.
The test manages to hit almost every aspect of BizTalk, including Messaging, Orchestrations, HWS, BAM, BAS, installation and management. That’s why the hands-on experience is so important.
Like this:
Like Loading...
