To state the obvious: with mission-critical applications, your mission will fail around the same time your applications do. This truism is of immediate concern to .NET developers involved with Service Oriented Architectures (SOA), the loosely coupled software services that now support all kinds of business processes, including supply chains and customer-facing online applications. Failures or even brief slowdowns can take immense tolls because, well, the company's mission itself is affected.

As numerous organizations are planning to embark on their first endeavors in service-oriented architecture (SOA), it is important to recognize that the necessary organizational transformation has as much to do with cultural transformation, as it has to do with open, Internet standards-based design. In fact, the very nature of how business and IT view each other's role and how the enterprise views its relationships with its marketplace partners and customers is being altered. Such cultural change has never come easily and represents a significant organizational dilemma.

Most organizations today have internal applications that span across different systems, networks, and technologies. These applications would provide more value to customers if only the data that they manage were exposed. In the past, this was often difficult due to the inability of systems to communicate with one other. However with Web service standards in place for several years now, services are finally gaining acceptance throughout the industry. Consequently, service-oriented architectures (SOAs) have finally come to fruition as companies start to rethink how they build enterprise applications.

You are an architect on your company's new flagship application. The app encompasses several business and technical domains that are, in your opinion, well suited to domain-specific languages (DSL). In years past, you would have turned to XML as the solution for all your DSL needs. With or without schemas, you would specify configuration files and scripts in files foul with angle brackets. Thankfully, for the discerning .NET architect, DSL implementation options are now plentiful.

Consider the following portion of an all-too-common server scenario. An authenticated user, perhaps a salesperson, requests a Word document from a server. The document is an expense report, and the server is an ASP, ASP.NET, or SharePoint Server. The server code looks up some information about the user from a database, Active Directory, or Web service. For example, perhaps the server has a list of recent corporate credit card activity that it will prepopulate into the expense list. The server starts up Word but keeps it 'invisible' because there is no interactive user on the server. It then uses the Word object model to insert the data into a table, saves the result, and serves up the resulting file to the user.

You might have been asking yourself for a while now what this Service Oriented Architecture (SOA) thing is and why it should matter to you. If you're a developer you've probably been wondering what you'll need to learn to avoid being left behind. You'd probably also like to know what steps you can take to position your development team and your organization for the future.

Mobile devices, such as the Microsoft Windows CE-based PocketPC, have grown significantly in popularity over the last several years. In the car, on a plane, or out in the middle of nowhere, applications on the device can operate without a connection to any other computers, the Internet, or an intranet. Devices can then partner with a desktop system either via modem or network card, or simply by placing the mobile device in a cradle.

With Whitehorse, Microsoft has placed a significant stake in the ground when it comes to modeling enterprise services. While Whitehorse is part of the not-yet-released Visual Studio 2005 (codenamed 'Whidbey'), Microsoft has publicly discussed and demonstrated significant elements of Whitehorse, and alpha code is currently in use by select Microsoft customers.

Today's enterprise applications demand high levels of reliability, scalability, availability, and interoperability. These demands have fueled the growth of complex service-oriented architectures (SOA) built on industry standards such as Web services and XML-based messages. The added complexity of these types of applications has increased the requirement for powerful tools and platforms.