If you often find yourself looking for the right way to describe technology to business leaders, you may be familiar with David Chappell. He does a great job of presenting content in a way that is understandable. His latest is a white paper about Indigo. It is available now for download from MSDN. Now, I’m not saying that this is not a technical white paper. It is. I’m just saying that you should become familiar with David Chappell’s other writings, as well.
1. “…Many people at Microsoft have devoted years of their lives to creating Indigo. This level of effort wouldn’t have been necessary if the problems it solved were simple or if their solutions were obvious. Accordingly, Indigo is a substantial piece of technology. Three things stand out, however, as Indigo’s most important aspects: its unification of several existing Microsoft technologies, its support for cross-vendor interoperability, and its explicit service-orientation.”
2. “…Indigo represents a modern approach to creating distributed applications in the era of reliable, secure, and transactional services. A key point to understand, however, is that installing Indigo will not break any existing applications. Current code running on ASMX, .NET Remoting, and the other technologies whose functionality is subsumed by Indigo will continue to run, and so there’s no requirement to move to Indigo. But for organizations with investments in current Microsoft technologies, an obvious question remains: what happens to existing code written using the technologies that preceded Indigo? “
3. “…Indigo represents an important evolution in how developers create software. As service-oriented applications become the norm, Indigo will be a mainstream technology for Windows software developers. Other Microsoft products will also change to take advantage of what Indigo offers. BizTalk Server, for example, will add support for Indigo as a communication option sometime following the release of BizTalk Server 2006. Because Indigo provides a standard foundation for service-oriented software, it will be the basis for a large fraction of Windows communication.
The impact of this technology will not be small. Anyone who builds distributed applications on Windows, especially applications that must interoperate with those on other platforms, should pay close attention. Indigo will significantly change their world.”
A colleague of mine, Todd Van Nurden, has written an ODBC adapter for BizTalk Server 2004. Download it from the GotDotNet workspace. The ODBC adapter addresses some of the limitations of the SQL Adapter. For example, it supports stored procedures that return multiple recordsets…
The Quick list:
Stored Procedures with out parameters (If the ODBC driver supports them)
Compound queries – More then one query performed in a single pass
Parameterization of raw SQL Statements (Enter your own SQL statements with parameters)
Batched queries – The request XML document can be nested with multiple parameter sets
It’s all good…
Paul of SolidSoft has a good introduction to BizTalk and the uber-term “SOA”. He describes how BizTalk offers value within a SOA environment when it fills one or more roles of these 3 patterns: Service Broker, Service Aggregator, and Integration Enabler.
Thanks to Doug for the tip.
This looks like a great start to a blog. The Customer Response Team for the Business Process and Integration team at Microsoft. Keep up the great information! If for no other reason, (besides the obvious list of doc links), it must be interesting because their stated purpose uses so many words that I had to look up…
Purpose of the Customer Response Team Blog:
The purpose of this blog will be to disseminate salient learnings and product information we’ve gained from running customer programs that may be of interest to the masses.
One interesting learning today… I was building a BizTalk Server machine that was designed to be a production server (production defined to mean no locally installed Visual Studio.Net, no local SQL Server, etc…) and ran into a problem where BizTalk couldn’t write a .dll file… After some nashing of teeth, it turns out that the BizTalk installation program requires permissions to the C:WindowsTemp directory, and the file name is a temporary name (so it’s different each time you execute the install). On a single server installation, VS.Net (and perhaps SQL Server), set the permissions on the WindowsTemp directory so that other apps can write to it… By not installing VS.Net on this particular machine, that setting was missing. Once I fixed that, the BizTalk instal finished fine. This is a simple work around, but one that can kill an evening or two if you don’t know about it. Enjoy.
I received the latest training calendar from NetDesk in the mail today…
The best classes on their schedule are the following…
- BizTalk Server 2004 (course 2157) April 4-8, 2005
- Commerce Server 2002 (course 2729) March 21-24, 2005
- Content Management Server 2002 (course 2730) May 2-5
<equal time> Any training vendors or independent trainers that have similar course targeted towards the Pacific Northwest states, please let me know, and I will post accordingly.</equal time>
<subliminal>get trained… get trained…</subliminal>