|
Wednesday September 19 2001 Servers and Relationships under the .Net Infrastructure How Enterprise Servers can help You For the Enterprise planning to support Web Services, there lie many alternatives as far as platforms and servers are concerned. Within the Microsoft .Net architecture that supports the Web Services model of application development and deployment is a series of Servers that assist not only in the application deployment, but also in the areas of maintenance, management, and security. As the .Net strategy evolves, it consolidates a mix of services (Windows platform, COM+, web servers, Web Services, and enterprise servers) into one framework, provides a growing range of .Net compliant languages, promotes a strong reliance on XML, and fosters a growing commitment to the internet. We see this, among other places, in the support for XML that has been integrated into the SQL Server and Exchange Server environments. Web Services are standardizing on the message exchange protocols that have evolved to support HTTP based requests, thus standardizing on the protocols supported within the XML initiative. The .Net infrastructure should really be looked at as a methodology, rather than a technology. .Net is an infrastructure; it is a technical framework that houses a community of technologies. By housing and networking technologies, we take fullest advantage of the benefits derived from these technologies working together. Microsoft, over the years, has developed and evolved their initially disparate products to work cohesively and provide an overall solution to the problem of supporting application development and deployment. If we look back in time, there were several things that caused the evolution we see today. When we look back to the era of the integrated office products, Microsoft started with Microsoft Office, which provided the everyday user with a set of tools which were easy to use because they were well integrated and provided the user with a standard interface with which to work. Along the same lines, they embraced standards such as ODBC that caused the relationship between compliant data models to be seamless and thus data exchange and integration into everyday work exploded. A solution then needed to be developed to solve integration problems with COM, CORBA, and JavaBeans. That solution was SOAP. As Microsoft worked to evolve their products and incorporate standards, the Internet was evolving and development and data interchange in the Internet environment took the forefront in the minds of the technological companies, and so standards such as XML, SOAP, and ROPE (Remote Object Proxy Engine) have arrived. The support of these standards in the form of a manageable set of tools has led to the .Net line of products that Microsoft is currently releasing. As we consider the long history of this evolution, including the development of HTTP and the Internet in general and the advent of Java as a chief competitor, we can see the need for a cohesive set of tools to manage the latest software development platform, the Internet. Instead of trying to study a technology, if we look at the .Net platform as a methodology provided to solve the problems of supporting Web Services we will more readily see how the tools will integrate. In the body of this article, we will take a look at some of the Enterprise Servers on offer from Microsoft. Since the available suite of .Net Servers is quite large, we will focus on the underlying operating system and two of the Enterprise servers: Application Center and BizTalk. Further details on these topics and more of the range of servers can be found in a forthcoming paper. Windows 2000, IIS, and COM+ The basis for support of any development platform is the core operating system components on which the platform resides. Microsoft has developed the Windows 2000 Server and Advanced Server operating systems to become the basis for supporting the application infrastructure necessary for Web Services and Internet applications. Windows 2000 also has a tighter integration with the COM+ application object infrastructure and IIS than previous versions of the operating system. The application servers that we will be talking about use Windows 2000 as the platform to operate on. They also take advantage of features of the operating system such as load balancing and clustering, as we will discuss further in the Application Center Server section to follow. IIS has a proved foundation as a strong platform for hosting web sites. The operating system enhancements coupled with IIS' proven reliability forms a strong foundation for Web Services sites. Application Center 2000 Server management has become a critical issue since our world has evolved to being dependent on the Internet 24 hours a day, seven days a week. Our culture is no longer as understanding if our favorite web page isn't available. This expectancy has evolved into products that allow for minimum downtime; in fact only unplanned outages should affect end users in today's environment. In the past we have had to work very hard at management of web sites and it was virtually impossible to ensure that all servers in our web farm were perfect at all times due to lack of appropriate tools. Application Center 2000 is the consolidated management tool for web farm support. When a large web site is developed the need for an extra step in the reliability and availability of the machines supporting the web site becomes important. Application Center 2000 takes advantage of the Windows 2000 load balancing and clustering technologies to provide maximum up time for web sites. Let's first define load balancing and clustering. There are two types of Load Balancing - network load balancing and component load balancing. Network load balancing is when the operating system ensures that each machine involved in the web site is doing its share of the work by distributing incoming traffic evenly across all available machines. Component load balancing is when the server software balances the number of calls to the individual program components balanced across all available servers. Clustering technology essentially makes many machines appear as one machine for maximum availability purposes. Application Center 2000 also uses clustering technology to allow administrators to perform maintenance on a machine involved in the cluster without causing the web site to be down by placing the status of a particular machine in a inactive or offline state. Let's look at a diagram of how a cluster is used when a browser connects to a web site.
In the diagram above, the browser on the left has referenced a specific website. As it gets the IP address to the referenced site, unknown to the browser, the referenced site is a cluster of computers that is represented by the single IP address. The master computer in charge of the cluster (the web farm controller in the diagram) then routes the request to the most appropriate computer participating in the cluster. The technology involved in Application Center 2000 also allows for ease of deployment of Web Services and sites that support Web Services. The Management tool allows automatic updating of a site on all participating servers in the cluster and reports back on the status of such events. The Application Center 2000 Server tools divide a web site's source files into sections, such as ASP pages, components, registry settings, and Web Services. Each section of the site can then be maintained independently which provides greater flexibility for program maintenance and stability. It is often the case that core component upgrades call for the restarting of a participating computer in the cluster; in this case Application Center 2000 handles the updating across the cluster of servers in such a manner that does not cause the site to go down. Let's look at a diagram of how this occurs.
As we look at the diagram above, we have a staging server in place where content and component updates are placed prior to being implemented in our server cluster. The staging server then communicates through a firewall to the Application Center cluster. Using Application Center 2000 we can write a script that updates each server in order, replacing any content needing updating and then rebooting the server and ensuring it is back online prior to updating the next server. BizTalk Server 2000 The BizTalk Server is a designed to assist in all levels of XML translation and integration functionality. From an historical perspective, BizTalk was an integral part of Microsoft's XML initiative, and so was one of their first products to utilize the HTTP, SOAP, and XML standards as its core functionality. Today, since Web Services are based upon the XML standards BizTalk will assist in a variety of areas when Web Services need to translate XML into different dialects, as well as being able to assist us in monitoring the status of messages used by our Web Services, even though BizTalk does not support Web Services 'out of the box'. Let's look at an overview of the total functionality that BizTalk can bring us. As we talk about the BizTalk functionality, we need to realize that BizTalk crosses a lot of business disciplines. The BizTalk Orchestration Designer assists in designing the business process that surrounds the transfer of data. For instance, Orchestration would help in designing a highly efficient process for sales, packaging, and shipment of inventory goods. In an orchestrated scenario, the people who make up the processes that surround the sales, packaging, and shipment could be prompted to action by the result of a program that utilized message queues and wireless devices, thus cutting down the time it would take for each process to be accomplished. It would take business people, IT people, and programmers working together with the Orchestration Designer as a tool to accomplish the automation of such a set of tasks. The BizTalk Editor and Mapper tools assist in automating the development of schemas that can quickly translate incoming and outgoing documents into a standard accepted by many industries. As an example of this, BizTalk can be used as a tool for EDI document translation. Electronic Document Interchange (EDI) has been a business practice for many years now in the areas of processing documents that relate to inventory, such as purchase orders and invoices. The standards for EDI document transactions have taken many years to evolve, and BizTalk is poised to be a key player in the future of EDI document exchange. This position will be secured by the tools mentioned above coupled with the Messaging Manager function which assists in setting up the trading partnerships area of EDI. The other feature that BizTalk provides is document tracking. Any document that passes through the system is tracked so that you can see where errors might have occurred, correct them, and cause a process to resume and complete. For instance, tracking EDI documents is very important from the standpoint of ensuring the document reaches all destinations that it is supposed to so that items get shipped on time, and accounting documents are processed on time. BizTalk lives in the environment essentially as an application server would, its main function being a "flow-through" point for XML messaging. As we said above, it functions as an XML document converter as well as a pipeline control point. In this scenario, the BizTalk Orchestration is working through the BizTalk Server to interact with mobile devices and the Server is also involved in some EDI messaging functions. The BizTalk Server would communicate with the remote EDI server on a periodic basis, and then process the EDI documents and integrate them into the software that processes them on the accounting server. In addition to this, as shown in the following diagram, the accounting system communicates with the BizTalk server, using it to communicate with mobile devices which pull inventory for shipment. The BizTalk server would also communicate with the accounting system when the inventory was pulled and shipped. Let's look at that diagram, illustrating how BizTalk server fits in the overall network architecture of a business:
Combining Enterprise Servers We have looked at a small part of the suite of .Net Enterprise Servers on offer from Microsoft, and how they can be used as part of a Web Services initiative. Although there are several more servers to complete the suite, we could use a small number to provide support for Web Services. The following diagram illustrates how BizTalk could work with Application Center:
In this example, we have a series of computers running as part of an Application Center cluster, each of which hosts the application we are exposing as a Web Service. The end user (be it a PDA or a more traditional desktop-based browser) requests the Web Service by use of an XML message, which is forwarded through IIS (our web server) to the BizTalk Server. BizTalk translates the message from SOAP into the dialect our application understands, and Application Center makes sure the most appropriate computer responds. The returning information goes again through BizTalk, where it is translated back into SOAP, then is forwarded by IIS to the calling device. Bingo - a simple means to provide Web Services, with only a small amount of integration required. Conclusion With their suite of .Net servers, Microsoft is aiming to provide enterprise level support for applications using Web Services, from the consumer to the publisher. With the addition of further servers, such as Mobile Information Server to specifically target presentation for mobile devices and SQL Server 2000 for data warehousing, a Web Service can easily be put together using the Microsoft .Net environment. If you're looking for a suite of servers to process and manage your enterprise level applications, the .Net Server range could well be it. Although they will only run on Windows platforms, there should be no problems integrating them. The extended PDF version of this article is now available Web Services and .NET Enterprise Servers by
Whitney Hankison Buy it from: our download site, or from Amazon.com |