Editor's Note - February 2002

  • Article

ed_note

Figuring Out .Net for IT

This is Part 2 of a three-part series of notes about .NET. Part 1 gives an overview of .NET from the IT perspective. Part 3 will describe a number of real-world IT apps and opportunities to implement .NET. What lies between is an IT-centered description of the individual .NET components.

Just to refresh, our standard Microsoft .NET definition of .NET goes something like this: .NET is Microsoft's platform for XML web services. XML web services allow applications to communicate and share data over the Internet or an intranet, regardless of operating system or programming language.

Here's my own definition, reflecting a personal IT bias (and in no way reflecting any Microsoft "official statement"): .NET is a feature-filled services platform for building web-based applications and developing rich interactive experiences for users and their systems. The small-w "web" includes both the Internet and intranets.

The IT slice of .NET includes servers, services, a platform of development tools and systems, and sometimes - where there is direct user interaction - clients. We'll look at the first three here, focusing mostly on the servers.

I know it sort of looks like I'm trying to sell you these products. I work for Microsoft, and paychecks here ultimately depend, of course, on our selling a bunch of products, so at that level I'm guilty as charged. However, what I'm really trying to "sell" is .NET. As I noted in Part 1, I believe .NET and web services can really help IT folks help their businesses and their users; I hope to get you thinking about these topics, and to share my own understanding of the .NET components.

Servers

There are at present 11 .NET servers. Some of these are primarily Internet servers, but most - Host Integration, SharePoint, Exchange, and SQL Servers, for example - are no less useful even if your company hasn't heard of the Internet.

Here's the current (January 2002) list, each with a brief description, thoughts on how it fits within IT, and links to more information. Because I suspect not everyone is familiar with each of these servers, I've included - as the first link for each server - "overview" links to general content in addition to links to technical, IT-focused content. Many of these latter links go deep into the details of critical areas of these servers and are not for the faint of heart!

One caveat - running a bunch of .NET servers isn't of itself "doing .NET." These servers are the underpinnings; see Parts 1 and 3 of this series for thoughts about what you might build on those underpinnings to enhance your business.

  • Use Microsoft Windows 2000 and the Microsoft Windows .NET Server family to build, deploy, manage, and run web services. I won't spend time discussing these core products here.

  • Use Microsoft Application Center 2000 to deploy and manage highly available and scalable Web applications. "AppCenter" is a great way to manage sites, handling the details and complexities of clustering, scale-out, and high-availability (HA). It allows you to treat multiple servers effectively as one box, which makes it a boon even for smaller IT shops who want a HA web presence without using highly specialized hardware or becoming a clustering expert. If you can manage single servers effectively, AppCenter will help you manage a cluster. (If your data center is run by James Bond or Harry Potter, AppCenter won't work miracles; it does, however, lower the bar to a height most IT shops can clear.) Click here for a technical overview, here to study the details of cluster setup, and here to see how AppCenter handles component load-balancing.

  • Use Microsoft BizTalk Server 2000 to build XML-based business processes across applications and organizations. It allows for graphical management of the processes; if you can use Visio, orchestrating processes with BizTalk will be a snap. (Okay, nothing that works across disparate systems is "a snap"; BizTalk does make this process manageable, which seems a pretty big win to me.) There are integrated queuing (or IBM MQSeries), support for EDI and XML, and both short- and long-term transactions. If you're doing B2B, or looking into it, BizTalk can help. By the way, it's a too-well-kept secret that BizTalk works within organizations too; it's a great way to move documents and data through disjointed processes. (Click here for the technical FAQ, here for the documentation.)

  • Use Microsoft Exchange Server 2000 for messaging and <a collaboration (that's Micro-speak for "mail"). I'm a big fan of Exchange with rich clients (Outlook); in a modern business, knowledge workers live in mail plus a word processor or spreadsheet. However, it's not well known that Exchange offers great options for users on slow links such as dialup. Here's a white paper. Also, here are my own thoughts on why this should matter to IT over the next few years.

  • Use the underappreciated Microsoft Internet Security and Acceleration Server 2000 as a network tool for secure, fast Internet connectivity, with versions for small businesses and for the enterprise. At the heart are a multilayer firewall and a web cache; it's easily configured, extended, or even programmed via COM.

  • Use Microsoft SQL Server 2000 to store, retrieve, and analyze structured data. It's got great performance and powerful business-intelligence tools, and it's very easy to use (that's relative to other RDBMSs, of course; DBAs aren't completely out of a job yet). You probably know this already. So let me offer two non-obvious suggestions. First, the BI tools let your knowledge workers do OLAP and data mining through Excel pivot tables or even the Web, without having to know anything about databases - and they can do so against any ODBC data store, such as products from Oracle and IBM. Second, XML for SQL Server, a/k/a SQLXML, lets developers create XML views of existing relational data and work with it as if it were an XML file. (I was trying to get through this server list without mentioning XML, but I couldn't quite do it. Sorry.)

  • Use Microsoft Commerce Server 2000 for quickly building scalable e-commerce solutions. If you're running your own B2B or B2C site, Commerce Server lets you profile and target customers (you'll use an appropriate privacy policy, I trust), build, import, or integrate a product catalog, deploy a variety of content, model your internal processing workflow, and analyze click and order data as part of a mission-critical environment.

  • Use Microsoft Host Integration Server 2000 for bridging to data and applications on legacy systems. "Never trust a computer you can't lift," the old saying goes - but if you do have one of those heavyweights, Host Integration Server connects it to the Windows world. (For what it's worth, this saying is neither apocryphal nor anonymous; Mike Perry came up with it ca. 1981 at a Forth Interest Group meeting in the Valley.)

  • Use Microsoft Content Management Server 2001 to manage content for web sites, e-business, and otherwise. Content is stored separately from presentation templates, which facilitates not only changes in design but the building of multilingual sites. As always, the doc is available on line.

  • Use Microsoft SharePoint Portal Server 2001 to find, share, and publish business information; the "Portal" in the name refers to corporate (internal) portals. It ties in directly to Microsoft Office and Internet Explorer on the desktop. It integrates easily with the other .NET servers, albeit not in an all-on-one-box configuration. And it sounds a lot like SharePoint Team Services. (Think enterprise vs. departmental and/or planned vs. ad hoc, respectively.)

  • Use Microsoft Mobile Information 2001 Server to bring the corporate intranet to mobile devices such as cell phones and do so securely.

Platform

I'm an old ex-developer of both commercial and IT software, and I think the .NET platform is the most exciting thing in the past six years (since scriptable browsers and, well, Java-the-language). And it's exciting for the same reason - it will make it easier for IT folks to develop professional-level business applications. As a commercial developer, I worked in C and various assembly languages; the object was to get every possible bit of speed and value into a product. As an IT guy, the game is radically different - build it competently, quickly, maintainably, and meet-your-users-needs-ably. (I think we need a new word here. Maybe there's no word because we don't focus enough on this last requirement.)

IDEs were the first hits in that new game; VB improved on it; scriptable browsers were another leap forward; and I think the .NET platform will have the same impact. Point your development folks to MSDN to learn more.

At the heart of .NET for developers is the NET Framework, the common language runtime (CLR) and class libraries underlying the overall .NET platform.

Third parties who develop for the .NET framework will include some new security features, primarily code signing and code access security. Code signing ensures that the code you're running hasn't been altered from the code delivered by the third party. Code access security enforces authorization; for code to run, the user or executer must have permission, the publisher must be verified, and the code itself must have the proper access levels.

I'm not claiming .NET is nirvana for developers, nor am I suggesting you throw out everything you know today about developing IT software. Rather, develop a growth-plus-migration strategy, whatever your current platform and language (even COBOL). .NET works across languages; it's not all-or-nothing.

The learning curve isn't all that steep, and the benefits to your users can be significant.

Services

Microsoft and others are creating a core set of building block services that perform routine tasks and act as a backbone that developers and IT shops can build upon. The first of these is .NET My Services (nee HailStorm), which itself is based on building blocks such as Passport and .NET Alerts.

There's been a lot written about these in the last few months, ranging from the accurate and detailed (both pro and con) to the silly and wrong (both pro and con). If you're engaged in - or plan to engage in - e-commerce, web services can simplify your life. And users of Passport might want to read first-hand what Microsoft is trying to do here. You, of course, are the judge of whether we're succeeding, but at least measure us against real goals rather than reportage! (Steve's truth-in-labeling: These links are not to TechNet pages, and are not necessarily spin-free. I think they're accurate, though, and they're not press releases - you do know I won't link to those, don't you?)

As I noted above, most knowledge workers spend the bulk of their time in a productivity product such as Office. As such, Office XP is the logical place to start thinking about bringing the power of web services to your users. If your IT shop does development of internal apps, take a look at the Web Services Toolkit.

Conclusion

I'll be honest; it took me awhile to figure out .NET. It also wasn't clear to me even six months ago that .NET and IT were ready to dance; if you as an IT specialist haven't paid much attention to .NET this past year, you haven't missed out on much - yet! But times change and products ripen, and economic down cycles are good times to get a jump on your competition. I believe that in 2002 you can use .NET to help get that competitive advantage.

It's important to note that .NET is not restricted to a Microsoft world. You can use .NET to connect to systems running a wide variety of operating systems; in fact, in most cases you don't even need to know what O/S the other system is using. Web services bridge applications and information written in different programming languages and residing on differing platforms. This works both internally as well as across the Web. Your HR and Accounting departments can now share information via XML, perhaps to create a new benefits application.

Next time out, in Part 3 of this series, I'll offer up some examples of how .NET can make a difference in real-world business situations. Meanwhile, if you have thoughts on .NET or anything we're doing (or not doing) on TechNet, please send them to me.

Steven B. Levy
Microsoft TechNet