Solutions Guide
February 2002 168Z-0202A-WWEN Microsoft .NET Web Prepared by: Internet and eCommerce Solutions Compaq Computer Corporation Services Solutions
Contents Abstract: This document identifies the technologies associated with Introduction...... 3 What is a Web Service?...... 3 Microsoft XML Web Services and documents best practices for Microsoft .NET...... 3 developing, deploying, consuming, securing, and managing a Web Microsoft Web Services...... 4 service. This document also discuses the performance, scaling, and .NET Technologies Used to availability concerns of Web Services. .NET is Microsoft’s Develop an XML Web implementation of an Internet application development platform Service...... 4 Deployment of XML Web using a suite of technologies, tools, products, and standard protocols. Services...... 6 The .NET Platform is used to develop XML Web Services (or .NET Consuming a .NET Web Web Services), which are Microsoft’s implementation of Web Service...... 7 services. An XML Web Services prototype example, with associated Private Web Services...... 8 Public .NET Web Services. .9 source code, is provided in an appendix of the document. Performance Considerations The target audience of this document is any individual who needs a ...... 10 Security Considerations....10 better understanding on how to develop, deploy, consume, secure, or Discoverable Web Service manage a Web service. The reader should already understand (UDDI)...... 14 Microsoft’s .NET and Web Services concepts. Management of Web Services...... 16 DISA and a Web Services. .20 The DISA Architecture...... 20 DISA Key Principles...... 21 Conclusion...... 22 APPENDIX A - Microsoft’s CLR...... 23 APPENDIX B - Example...... 25 Overview of a B2B Web Service Demonstration...... 25 Sample Web Service Processing Flow...... 29 Files and Code Samples of Sample Process Flow...... 31 APPENDIX C - System Software...... 35 APPENDIX D – References 37 APPENDIX E - Glossary.....43 Microsoft .NET Web Services Solutions 2
Notice This publication does not constitute an endorsement of the product or products that were tested. The configuration or configurations tested or described may or may not be the only available solution. This test is not a determination of product quality or correctness, nor does it ensure compliance with any federal, state or local requirements. Compaq, the Compaq logo, ActiveAnswers, Compaq Insight Manager, SmartStart, SoftPaq, and ProLiant are trademarks of Compaq Information Technologies Group, L.P. in the U.S. and/or other countries. The .Net logo, Microsoft, Windows, Windows NT, BizTalk, SharePoint, Visio, Visual Basic, Visual C#, Visual Studio, Win32, and Visual C++ are trademarks of Microsoft Corporation in the U.S. and/or other countries. All other product names mentioned herein may be trademarks of their respective companies. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information is provided “as is” without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty. ©2018 Compaq Information Technologies Group, L.P. Microsoft .NET Web Services Solutions Solutions Guide prepared by Internet and eCommerce Solutions First Edition (February 2002) 168Z-0202A-WWEN
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 3
Introduction Today most businesses on the Internet revolve around websites, which typically do a good job of providing information to a user. These websites can support transactions and commerce using the Internet. Typically, these websites fall into two general categories: a static or brochure type of site, or a dynamic or commerce site. Other types of businesses on the Internet include non-website-centric businesses like Business-to- Business (B2B) and market exchanges. These types of businesses are still evolving and are a fertile ground for the technology referred to in this document. For these businesses to evolve on the Internet, they must use methods to interact with one another as well as with users, other applications and systems. Web services represent the evolution of the website. Taking the modular aspects of modern software applications and allowing them to communicate through standard Internet protocols, such as XML1 and SOAP2, Web services offer a direct means by which business processes can interact. Applications hosted internally, as well as on remote systems, can be stitched together, allowing businesses to program the Web—quickly and economically creating specialized solutions that meet unique business needs. Compaq enhances Microsoft .XML Web Services by providing an implementation and deployment blueprint as well as a set of recommended best practices based on years of experience deploying the Compaq Distributed Internet Server Array (DISA) architecture. Microsoft XML Web Services can be readily deployed in a highly available and scalable fashion using the DISA architecture. This document addresses how to decrease both the implementation time and risk associated with the deployment of Microsoft XML Web Services. What is a Web Service? A Web service is a piece of business functionality exposed via Internet protocols. Web services are Internet-based modular applications that perform a specific business task and conform to a specific technical format. The modular technical format allows for these self-contained business services (from the same or different companies) to mix and match easily to create a complete business process. Microsoft .NET .NET is Microsoft’s implementation of an Internet-application-development platform using a suite of technologies, tools, products, and standard protocols. The .NET Platform is used to develop XML Web Services, which are Microsoft’s implementation of Web services. There are many definitions for what .NET is (and is not). It is not within the scope of this document to define .NET, but to discuss Microsoft XML Web Services in the context of .NET technologies. Below are just a few of the definitions currently available for Microsoft .NET:
1 An initiative from the W3C defining an "extremely simple" dialect of SGML suitable for use on the World-Wide Web. http://www.w3.org/TR/REC-xml.html 2 Simple Object Access Protocol (SOAP) is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML-based protocol that consists of four parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, a convention for representing remote procedure calls and responses, and a binding convention for exchanging messages using an underlying protocol. http://www.w3.org/TR/2001/WD-soap12-20010709/ http://www.soaprpc.com/mirror/ietf/draft-box-http-soap-01.txt.html
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 4
“Microsoft .NET is an XML Web services platform that will enable developers to create programs that transcend device boundaries and fully harness the connectivity of the Internet.” (Source: Microsoft: Welcome to the MSDN Library) “Microsoft’s .NET is a company-wide effort to move Microsoft’s developers, products, customers, and services from the client-server computing model to Microsoft’s vision of the Web services model” (Source: The Burton Group: Network Strategy Report) “.NET is an all-inclusive Web-based software architecture for internal and external use. Microsoft browsers, applications and new versions of Windows will be .NET enabled.” (Source: TechWeb Encyclopedia) “When you look at the fundamentals about what's happening with .NET, this is the ability to really create a very rapid deployment at a much lower cost of Internet applications,’ Michael Capellas, CEO of Compaq Computer Corp., told reporters during a break in the meeting. ‘It's freeing our applications developers not to have to worry about all the basic-level services. It lowers the cost and creates a much better user experience on the front end,’ he added. ‘It actually finally allows us to really come with a much, much more rapid development process around Internet applications.’ Calling .NET ‘a major move,’ he emphasized that Compaq is ‘going full-bore behind" the strategy.’ ” (Source: BridgeNews Bulletins, Thursday, May 24, 2001) Microsoft Web Services Microsoft XML Web Services are Microsoft’s implementation of XML-based Web services and are developed using .NET platform technologies. This section of the document assists the reader with some of the infrastructure issues associated with deploying .NET Web Services.
.NET Technologies Used to Develop an XML Web Service
.NET Enterprise Servers: – Application Server 2000 – BizTalk Server 2000 – Commerce Server 2000 – Content Management Server 2001 – Exchange Server 2000 – Host Integration Server 2000 – Internet Security and Acceleration Server 2000 – Mobile Information Server 2001 – SharePoint Portal Server 2001 – SQL Server 2000 Windows 2000 Servers: (Windows Family Home Page) .NET Framework: (.NET Framework). A Windows run-time environment that provides an enhanced set of system-level functionality designed to assist in the development and management of Microsoft XML Web Services:
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 5
Common Language Runtime (CLR) Managed Code: Provides a richer set of OS Services than is available to the Win32 OS itself. (Additional information on Microsoft’s CLR can be found in the Appendix) – Memory Management (Automatic Garbage collection of Methods and Objects no longer in use) – Version Management (DLLs, EXEs) – Object Oriented Programming (OOPs) support across languages (same feature sets across multiple languages) – Hierarchical Namespace organization – Code Security (built in granular security controls) – Interoperability with COM (uses a Runtime Callable Wrapper (RCW) to run a COM object from a .NET Client and a COM Callable Wrapper (CCW) to run a .NET object from a COM Client.) – ASP.NET (.NET version of Active Server Pages): It includes a tool (.NET Web Forms), which is an easy to use UI for ASP.
Visual Studio.NET: ( Microsoft Visual Studio: Microsoft Visual Studio .NET - Next Generation) – Visual Basic – C++ – C# – Other Languages see: http://msdn.microsoft.com/vstudio/partners/languages/default.asp
.NET Windows Forms: (Introducing Windows Forms) A new forms package that provides an interface UI design environment for the features of the .NET Framework. In addition, there are other standard technologies used by .NET (Reference: Welcome to the MSDN Library): ADO.NET - ActiveX Data Objects, Microsoft's high-level interface for data objects. XML - Extensible Markup Language, a specification developed by the W3C. XML is a pared-down version of SGML, designed especially for Web documents. HTTP - HyperText Transfer Protocol, the underlying protocol used by the World Wide Web. SMTP - Simple Mail Transfer Protocol, a protocol for sending e-mail messages between servers. TCP/IP - Transmission Control Protocol over Internet Protocol. TCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts to establish a connection and exchange streams of data. SOAP – Simple Object Access Protocol (SOAP) is a lightweight protocol for exchange of information in a decentralized, distributed environment. SOAP relies on the use of a transport protocol, and while it is not tied to a particular transport protocol, currently HTTP is the only one that has been defined by the W3C.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 6
UDDI - Universal Description, Discovery and Integration creates a platform-independent, open framework for describing services, discovering businesses, and integrating business services. WSDL – Web Services Description Language is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. Visual Studio.NET has the ability to auto- generate proxies of Web services based on WSDL. This feature automatically allows developers to have an SDK to work with at the object level without having to do string manipulation to build SOAP Requests.
Note: Additional information can be found in the Glossary in APPENDIX E - Glossary.
Deployment of XML Web Services While a Microsoft XML Web Service (Web Service) can be defined as any URL-addressable resource that provides Web-exposed business functionality, there are standards and technologies that have been developed to facilitate the implementation of Web Services.
Creating and Publishing a Web Service By publishing a Web Service, an application can be created that exposes functionality to clients via the Web. Creating a Web Service is similar to creating any component that provides programmatic access to its application logic. To create a Web Service, you need: Functionality that constitutes the service you wish to expose A service description that defines how to use the service A messaging infrastructure to support request processing and response dispatch Publishing a Web Service is the process of creating application code that handles requests and responses as method calls. These method calls take parameters and return values. There are three basic steps involved in Web service creation and publishing: Create your Web Service Test the Web Service using remote debugging Publish your Web Service to the server from which it will be accessible and verify that it is accessible from a client. Publishing a Web service involves: – Deploying your solution to the Web server on which it will reside – Creating the necessary discovery mechanisms so that users can find out about your service and make use of it.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 7
Web Services are made available to users via a discovery mechanism that usually takes the form of a dynamic discovery document. The discovery document contains a reference to the WSDL (Web Service Description Language) description location. End users browse the root of the Web server to locate discovery documents, and from these files, they determine what services are available to them. This discovery document is deployed with the project and placed in the directory in which the solution is installed on the server. For example, suppose you have a Web application project created in Microsoft VisualStudio.NET named StockServicesSolution that contains a Web service named StockServices. By default, the solution contains a discovery file called StockServices.disco. When you deploy this solution to the server, the following structure is created:
\inetpub \wwwroot \StockServices StockServices.disco StockServices.asmx Other files for your Web Service
End users can access this discovery file by accessing its URL. In this case, the URL would be http://webserver/StockServices/StockServices.disco. The .NET Framework provides the infrastructure on which to develop Web Services. This infrastructure includes built in SOAP support, a Web Services Description Language (WSDL) Tool, a Web Services Discovery Tool, XML Schema Definition Tool, Code Access and Role Based Security, and built in Web Service support to handle XML, POST, GET and SOAP.
Consuming a .NET Web Service To access a Web Service, you need: To locate a Web Service that provides needed business functionality To locate the service description that defines how to use the service To use a messaging infrastructure to support request processing, and response dispatch The location of a Web Service, as well as the service description, is accomplished using UDDI (Universal Description, Discovery, and Integration). The goal is to create and operate a global registry for business-to-business commerce over the Internet. The service description is composed of WSDL (Web Services Description Language). WSDL is an XML-based language used to describe programs accessible via the Internet (or other networks), and the message formats and protocols used to communicate with them. WSDL is important because it enables Web Services to describe their capabilities in a standard way, enabling easier interoperability among Web Services and development tools. A Web Service can be consumed via three different methods: HTTP POST, HTTP GET, or SOAP. SOAP (Simple Object Access Protocol) is an Internet-friendly way of using XML to send messages and access dynamic Web Services across distributed networks. Typically, Enterprises will deploy two types of Web Services: secure and public. A secure Web Service is one published for use by an enterprise’s trusted trading partner or customer. A public Web Service is published and available for everyone to consume with few privacy or security requirements.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 8
Private Web Services Enterprises will have the need to publish Web Services that are going to be consumed by trading partners or customers. Since these types of Web Services will be consumed by these organizations to conduct business, they will become mission critical to all parties involved. With mission-critical requirements for the Web Services, availability and scalability become critical attributes of the components within the architecture. Figure 1 shows a typical scenario for hosting the Web services.
Corporate DMZ Network
F F i i ERP System SOAP .Net r Web r Service SOAP e e SOAP w BizTalk w Trading Partner Server .Net non-port 80 access a 2000 a Web l l Service l Application l SOAP
Figure 1: Private Web Service consumed by a trusted trading partner.
In this scenario, the Web Service is published and consumed by the trading partners on the DMZ. An example of this transaction would be the need for the trading partner to submit SAP orders into the organization. The port used to access the Web Service is determined by an agreement between both parties involved – the trading partner and the enterprise. The requests come in the form of XML documents from the trading partner. The first step is a farm of Web/application servers running Microsoft BizTalk Server 2000. Using a farm of servers, rather than a single server, is done for availability and scalability. In this scenario, BizTalk Server 2000 serves multiple purposes – XML document validation and authentication, aggregation of various XML schemas to one common scheme, and guaranteed message delivery. Next is the use of the published Web Service. In this scenario, the Web Service is used to publish data consumed from another Web Service or as an adapter for a back-end ERP system. Using the Web Service as an adapter eliminates the need for highly customized software and communications components.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 9
Another use of a Web Service in this scenario is to have an application in the DMZ consume data from a Web Service located in the corporate network. This type of transaction uses Simple Object Access Protocol (SOAP), eliminating the need to have multiple ports open on the back-end firewall. In all instances, the Web Services are hosted on farms of Web servers using load balancing to provide scalability and availability.
Public .NET Web Services In addition to secure Web Services, enterprises may have occasion to publish data that is to be consumed by everyone. This type of Web Service does not require authorization, authentication or privacy. Examples of these types of Web Services would be ones that provide the company’s stock price or a current listing of products. Figure 2 shows this type of deployment.
Corporate DMZ Network
F F i i ERP System r .Net r SOAP Web e Service e SOAP .Net Web Anonymous User w w Service port 80 access a a l l l l
Figure 2: Public Web Service consumed by anonymous users.
In this scenario, an anonymous user consumes data published from a Web Service within the company’s DMZ. Since the company wishes to make this available for everyone, the request uses port 80. In this example, the Web Service is used to publish the latest product listings from the company’s back-end ERP system or to publish data that is consumed from an internal Web Service. In all instances, the Web Services are hosted on farms of Web servers using load balancing to provide scalability and availability.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 10
Performance Considerations As with most applications, performance should be addressed. When considering performance, two attributes should be looked at – the Web Service itself and the platform for the Web Service. Web Services have the ability to consume and publish data. With this in mind, it is easy to see that Web Services that are not planned correctly will run into performance issues. For example, consider a Web Service that consumes from another Web Service. The performance of the Web Service that is consuming is dependent on the performance of the Web Service it consumes from. Further, without knowing the design of the Web Service that you are consuming from, you can get into a situation where you consume from a Web Service that consumes from a Web Service, which consumes from yet another Web Service, and so on. This type of daisy chaining may lead to performance problems. Further, this type of implementation leads to availability issues should one of the Web Services in the chain fail. The platform for hosting the Web Service should also be addressed when considering the system’s performance. For this reason, Compaq recommends a Scale Out approach when scaling the Web/Application Server resources. Scaling out is often the better approach when applications can support session state management and/or when load balancing provides a more cost-effective solution and/or when Internet services can be distributed across multiple servers. Advantages to scaling out are: Scalable and highly available services can be deployed, allowing capacity improvements without interruptions. Servers can be maintained and supported much more easily since services are not required to go down to add or remove a server for repair or replacement. There are linear and predictable costs associated with scaling out an application across multiple servers. Disadvantages to scaling out: Depending on the application, the cost per server and the cost of hardware load balancing may be higher than an implementation on one server. Software licenses may be higher when licenses are sold on a per-server basis. Management may increase for each server added to the array if appropriate best practices are not defined for the environment. For a complete discussion on Scaling Up and Scaling Out, see the Compaq white paper titled “Scaling Up and Scaling Out with Compaq ProLiant Servers and Microsoft Windows” found at: http://www.compaq.com/activeanswers.
Security Considerations As stated earlier, privacy and security become most important when publishing a Web Service for doing business with a trading partner or customer.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 11
Security Technologies HTTP offers support for many security technologies. There are three areas of security in e- commerce transactions: authentication, authorization, and privacy. Authentication verifies the identity of the requestor of services. Authorization verifies that the given identity has access to the requested services. Privacy guarantees that the message cannot be read, copied, or manipulated in transit.
Authentication Authentication can be done with the HTTP protocol and, in the future, in the SOAP message (if a legal extension to the SOAP protocol were made). The IBM Research Center in Tokyo has submitted a Note to the W3C to propose a legal SOAP extension that is nearly equivalent to the SSL client-certificate approach. The extension uses the SOAP Header to transmit authentication information and to guarantee data-integrity at the same time. While this Note has been submitted to the W3C suggesting an extension to the SOAP protocol, until it is accepted or approved the only viable option is to let authentication be handled by the HTTP protocol. The table below lists the authentication options within HTTP when using Microsoft IIS as the Web server. Basic Use for non-secure or semi-secure identification of clients, as username and password are sent in plain text. IIS will authorize access to the Web Service if the credentials match a valid user account. Basic over SSL Same as Basic authentication except that username and password are sent over the network with SSL encryption rather than in plain text. A good option for Internet scenarios; however, using SSL has a significant impact on performance. Digest Uses hashing to transmit client credentials in a secure way. However, not widely supported on non-Windows platforms. IIS will authorize access to the Web Service if the credentials match a valid user account. Integrated Useful only for intranet scenarios. Uses NTLM or Windows Kerberos. It can’t be used across proxy servers or other authentication firewalls. IIS (or other security application) will authorize access to the Web Service if the credentials match a valid user account. Client Requires each client to obtain a certificate. Certificates certificates are mapped to user accounts, which are used by IIS (or other security application) for authorizing access to the Web Service. A viable option for Internet scenarios, although use of digital certificates is not widespread at this time.
The Basic, Basic over SSL, Digest, and Integrated Windows authentication (NTLM) methods all rely on passwords to authenticate a user. However, Basic authentication sends passwords over the network in clear text. In certain circumstances, Basic over SSL will also send passwords over the network in clear text. Basic over SSL can be made relatively secure with additional modifications that allow the password to be encrypted.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 12
If a password-based scheme is not sufficient to authenticate the user, the Secure Sockets Layer (SSL) architecture allows verifying the identity of users through client certificates. The protocol known as HTTPS is really HTTP over SSL. These client certificates are a result of Public Key Infrastructure (PKI) technology. PKI forms the technology that issues, manages and validates digital certificates. A digital certificate issued by a certificate authority (CA) binds a public key to a specific user and details the operations it can be used for, as well as its validity duration. It also identifies the CA that issued it with the issuer's signature. This public key can be used in concert with its associated private key to authenticate the user and perform cryptographic operations. A digital certificate can be assigned to a server or to an individual.
Privacy As with authentication, there are two ways to go about it: by HTTP protocol or by SOAP extension. The IBM proposal mentioned above also covers the extension variant for privacy; however, as this extension has not been approved, only the HTTP protocol options will be considered in this document. For HTTP, the choice is obviously HTTP over SSL (HTTPS). HTTPS is a secure protocol that will encrypt all traffic between client and server. With the recent changes in U.S. legislation, 128- bit wide, strong encryptions keys are now available almost anywhere, and SSL is the most widely deployed privacy infrastructure for e-commerce. Because HTTP's integration with SSL is transparent for the implementation of HTTP services (although it comes with some cost in performance and scalability), it can readily be used with any SOAP implementation that sits on top of an HTTPS-aware infrastructure.
Authorization Privacy and authentication can be achieved by using either HTTPS with a password-based scheme or HTTPS with digital certificates. However, possibly the most difficult aspect of security can be authorization. The use of digital certificates for authorization is extremely inflexible. Each certificate is issued with V3 attributes that cannot be altered. If a user’s access level changes, a new certificate must be issued. Either before or after a user is authenticated, you must decide if the identity presented is authorized to have access to the requested system, data, or functionality. The trust policy must be managed and enforced at the application level. The application level contains the code that accesses and processes all sensitive data such as purchase orders, prices, revenues, customers, employees, salaries and so on. This is further emphasized because of the need for outside B2B users to be given access to a specific application or Web Service. Applications, which typically have unrestricted access to pass traffic through a firewall as needed, are expected to check these users against their own access control list.
Security Strategy While the SOAP specification does seemingly ignore all security issues, the infrastructure to deploy SOAP on HTTPS in a secure way exists now. By using all features of SSL (including client-side certificates), authentication, integrity and privacy can be guaranteed for all traffic. For password-based authentication, RFC2617 can replace client-certificates and still be used with SSL encryption. In addition, the SOAP extensibility mechanism allows for the extension of the protocol for the purpose of introducing message integrity, privacy and even authentication within the message itself in a way that is compliant with the specification but, most importantly, optional.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 13
Access to secure Web Services published and shared with trading partners should be severely restricted as these Web Services provide direct access to business logic functionality and data. Some items to consider for restricting this access are: The inside firewall protecting the Corporate Network should not allow any traffic over port 80. The inside firewall protecting the Corporate Network should allow HTTPS traffic on a port not known to the outside world. The inside firewall protecting the Corporate Network should restrict HTTPS traffic on a point-to-point basis. (For example, a known/trusted IP address to another known/trusted IP address) The Web Services should run under a specific local user account thus restricting access to the COM components or managed classes to that user account. This account will have limited privileges (no write access, or local admin, etc.) Digital Certificates are the most secure solution. If certificates cannot be supported, an SSL encrypted password-based authentication scheme should be used. Authorization should be handled by mapping the user name and password to a local account on the Web server. For custom-developed Web Services, each Web Service should satisfy only one particular XML function. All Web Services should validate the incoming message (SOAP Request) against the schema before processing the request. All machines hosting Web Services that use SSL traffic should be equipped with an SSL acceleration controller(s) or other means of accelerating SSL processing. This provides a true performance increase while using SSL.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 14
Discoverable Web Service (UDDI) For Web Services to be utilized, they need to be discoverable to businesses on the Internet. Therefore, UDDI is considered an important part of the Web Services protocol stack, and thus an important aspect of the Microsoft XML Web Services offering.
What is UDDI? UDDI, which stands for Universal Description, Discovery, and Integration, is a global registry managed by Microsoft, IBM, and Hewlett Packard that allows any business to discover and be discovered by other businesses from anywhere around the world so that they may conduct economic transactions more efficiently. Think of UDDI as the “yellow pages” for the Internet. In addition, UDDI not only allows for the discovery of trading partners but also describes services, whether they are Web Services or manual services. UDDI is more than a search engine for businesses and the services they provide. Discovering potential partners is only part of the solution. More importantly, a means of communication among your many varying partners must be inherently defined in a dynamic way regardless of the platform or application they are using to conduct business. In an ideal environment, an internal business application, which will be UDDI aware, will go out on the Web, search the UDDI registry, identify and download technical specifications to allow seamless integration between the internal application and the discovered external one, and conduct automated transactions with little to no human intervention. For example, suppose a company wanted to order auto parts electronically via the Web. An individual at that company would access an internal service to search the UDDI global registry, a Web Service in itself, for all suppliers of auto parts. Once the service has “discovered” all potential suppliers, the next objective is to identify which suppliers provide an online order entry Web Service. Finally, once multiple trading partners are identified that expose this service, it must be determined if the internal business application (electronic invoicing Web service) is compatible / interoperable with those discovered. Work is currently underway to provide enterprises with a private implementation of UDDI Business Registries (UBR). This UDDI implementation would help a large organization register and manage its internal Web Services, an example being Enterprise Application Integration. In this implementation, the entries are for Web Services provided by departments or groups within an organization. This type of UDDI implementation is completely hidden from external users behind an enterprise’s firewall. Publish-and-find operations are completely restricted to applications within the enterprise.
Why use UDDI? In developing a Web Service, UDDI should be used primarily to stay competitive with other companies using Web Services. Without adopting the UDDI initiative, the organization runs the risk of overlooking multiple revenue streams from acquiring new trading partners. More importantly, the business’ existing suppliers / vendors will go else where to conduct business in a more efficient / automated fashion through UDDI and Web Services. Web Services are the next logical evolutionary step in the Internet space that allows programmable elements to be called by other applications (Application-to-Application (A2A) Integration) in a distributed manner.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 15
Without UDDI, businesses that want to conduct transactions with their trading partners (partners by choice or coerced partnerships) must either build their own proprietary software or leverage someone else’s technology, which can become very costly. As the numbers of businesses expand online, so have the numbers of proprietary software for A2A integration. This influx of in-house software has created a Web of non-standardized forms of communications that has led to a slow time to market for products and services. With the adoption of UDDI, time to market for services are reduced, and A2A integrations on independent systems lead to smoother, more efficient transactions, the way the Internet was meant to be.
What problem does UDDI solve? No longer do you have to be a fortune 500 company with the financial depth needed to implement or lease proprietary software in order to conduct B2B e-commerce. UDDI essentially levels the playing field for companies of all sizes – small, medium, and large – to dynamically discover and be discovered, as illustrated in Figure 3, which relates to higher profit with little to no additional cost (marketing). In addition, a standardized specification for doing business will alleviate the need for many businesses to purchase very expensive proprietary technology.
Figure 3. A UDDI registry node exposes the registry contents using a standard, SOAP-based API. Registry nodes also replicate the registry data with one another to ensure changes at the one node are propagated to all nodes. Source: www.xmlmag.com
As more and more businesses transform their business functions into Web Services, it has become imperative for companies, small and large, to discover, describe, and integrate incompatible systems and applications to stay competitive in the B2B marketplace. In essence, UDDI provides three distinctive types of data: 1. White Pages data = name of the organization, contact name, phone number, address, and other general information
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 16
2. Yellow Pages data = displays multiple categories based on industry-standard taxonomies such as NAICS (North American Industrial Classification System), geographic location, and the products and services that they provide. 3. Green Pages data = Displays a company’s key business processes such as the applications supported by their system, payment methods, shipping requirements, billing requirements, and types of protocols supported. More importantly, it displays or directs you to technical specifications necessary for applications to locate and consume Web Services with other companies or applications. With these three types of data, any company can register and indicate the services they provide on the UDDI registry node. Buyers and vendors will search the UDDI registry for trading partners in hopes of getting a competitive advantage in the market, as illustrated in Figure 4. Company specifications will be published and accessible by other organizations for system / application interoperability.
Figure 4: Functionality of UDDI Registration
Management of Web Services Maintaining a website and Web Services is as important as maintaining a vehicle. For example, you can change the vehicle's oil regularly, much the same as updating your system to the latest revision. Similarly, you could choose not to so do and experience costly downtime that could just as easily have been prevented with a few minutes worth of work at a minimal cost. Verifying that resources are not being depleted or that a component in the system is beginning to fail could provide invaluable insight to the availability required by Web Services.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 17
Tools and Services Compaq and Microsoft provide tools that assist in effectively managing Web Services and monitoring performance to maintain response time and provide consistent availability while targeting a lights out operation. Tables 1 and 2 outline many of the various tools and services available from Compaq and Microsoft. Most of the software-based tools from Compaq are located in the Compaq SmartStart and Management CDs provided with every new server or can be downloaded from the Compaq website. Most of the tools listed below from Microsoft can be found on the Windows Server installation CD, or Product Application CD. Table 1: Compaq and Microsoft Tools and Services Available
Special Hardware System Management Application Services Management Tools Tools Management Tools Compaq Compaq SmartStart Compaq Integration Microsoft SQL Pre-Failure Server Manager Compaq Survey Utility Warranty Compaq Insight Microsoft Internet Compaq System Manager Information Services Partition Utilities Manager Compaq Network Compaq System Management Software Microsoft Partition Administration Management Compaq Insight Compaq Automatic Console Manager XE Recovery Server Microsoft Application Compaq Availability Compaq Standby Center 2000 Agents Recovery Server Microsoft Remote Compaq Integrated Access Services (RAS) Remote Console Microsoft Dial-Up Compaq Remote Insight Networking Lights-Out Edition Microsoft Netmon Compaq Asynchronous Management Microsoft Performance Monitor Compaq SNMP3 Agents Microsoft Terminal Server
Table 2: Compaq DISA Architecture Management Components
Component Hardware System Management Application Management Tools Tools Management Tools Local Management Compaq SmartStart Integration Server Microsoft SQL Server Console (repository for Agent Compaq Survey Utility configurations) Microsoft IIS Manager Compaq System Compaq Insight Partition Microsoft Application Manager Administration Utility Center 2000 Compaq Insight Compaq Remote Manager XE
3 SNMP (Simple Network Management Protocol) is a network management protocol that was designed to create a communication medium between different type networks. The primary functions performed by this protocol are: reading terminal data, setting terminal data, and trap network events, such as terminal startups or shutdowns.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 18
Component Hardware System Management Application Management Tools Tools Management Tools Insight Lights-Out Microsoft Performance Edition Monitor Three (3) Analog Microsoft Remote (POTS) lines for dial- Access Services up access (RAS) Compaq SNMP agents Remote Management Analog (POTS) line for Compaq Insight Compaq Availability Console dial-up access Manager Agents Compaq SNMP Compaq Insight agents Manager XE Microsoft Dial-Up Networking Firewall Compaq SmartStart Compaq Insight Firewall vendor Manager management tool Compaq Survey Utility Microsoft Performance Compaq System Monitor Partition Administration Utility Compaq Remote Insight Lights-Out Edition Analog (POTS) line for dial-up access Load Balancer Compaq SNMP Vendor supplied tools agents Web and Application Compaq SmartStart Compaq Management Microsoft IIS Manager Server Layer Agents Compaq Survey Utility Microsoft Microsoft Performance Management Console Compaq System Monitor Partition Compaq Availability Administration Utility Microsoft Netmon Agents Compaq Integrated Microsoft Application Remote Console Center 2000 Compaq Remote Insight Lights-Out Edition Analog (POTS) line for dial-up access Compaq SNMP agents Database Firewall Compaq SmartStart Microsoft Performance Firewall vendor Monitor management tool Compaq Survey Utility Compaq System
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 19
Component Hardware System Management Application Management Tools Tools Management Tools Partition Administration Utility Compaq Remote Insight Lights-Out Edition Analog (POTS) line for dial-up access Data Resources Layer Compaq SmartStart Compaq Management Microsoft SQL Server Agents Manager Compaq Survey Utility Microsoft Performance Compaq Availability Compaq System Monitor Agents Partition Administration Utility Microsoft Netmon Compaq Remote Insight Lights-Out Edition Analog (POTS) line for dial-up access Compaq SNMP agents Network Access Compaq SNMP Microsoft Netmon Network access Device agents device. Vendor supplied management tools
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 20
DISA and a Web Services The Compaq DISA architecture is a natural and complementary architecture with both Web Services development and the .NET Framework. DISA’s multi-layer model is directly complementary with Microsoft’s three-tier .NET development architecture. The Microsoft architecture recommends a presentation tier, a business logic tier and a data tier. In Compaq’s architecture for deployment, Compaq recommends an access and acceleration layer (for load balancing, firewall and caching devices), a Web and application layer, and a data resource layer. These two architectures provide synergies for design, development and deployment of distributed applications.
The DISA Architecture The Compaq Distributed Internet Server Array (DISA) architecture, illustrated in Figure 5, is a blueprint and set of recommended best practices for deploying highly available and highly scalable e-commerce/Internet applications.
Clients Internet Access Clients
Load Access & Microsoft Windows NT Acceleration Load Balancing Service Balance Resources (WLBS) r Web Servers Web & & Application Application Resources Servers
Data Data Servers Resources
Figure 5: DISA Architecture
DISA Key Principles Use multiple application servers rather than a single server. When combined with intelligent load-balancing technology, multiple application servers are more scalable and available than a single server with additional processors and memory. In cases where availability is critical, Compaq recommends a minimum of three servers, allowing for a single server to be serviced offline while keeping a redundant pair of servers online at all times. Application servers may have one or more processors, depending on the characteristics of the particular application. By using appropriate load-balancing technology, it may be possible to combine servers with different processing power and I/O characteristics into a single application server array.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 21
When applicable, data resources, such as static content and application code, can be centralized on amply-configured, highly-available data resources layer servers rather than replicating them on the application servers in the Web and applications resources layer. If appropriate fail-over techniques are applied, centralized data resource servers can simplify the task of managing rapidly changing application resources. Centralizing application resources also simplifies capacity expansion and failure recovery. To minimize downtime and ensure good performance, data resource servers should be amply configured with multiple processors, sufficient RAM, and redundant components (NICs, power supplies, and fans). Clustering technologies significantly improve the availability of centralized resources. Again, it should be noted that based on business requirements and application support, centralization may not always be appropriate. Use redundancy at potential single points of failure. Fail-over configurations are advisable for load balancers, firewalls, and networking devices. Intelligent load-balancing technology provides fail over for redundant application servers. Clustering databases and network storage ensures uptime for data resources. Redundant NICs, power supplies, and fans are advisable to enhance uptime on data resource servers. Redundant network connectivity through multi-homing and an uninterruptible power supply (UPS) are also advisable. The right degree of redundancy depends on the underlying business requirement and the available budget. Build applications to ensure that user state information is not maintained on a single application server. Applications that maintain user state on a single-application server may not function with certain load balancing algorithms. Some load-balancing products avoid such problems by managing load on an individual user basis to ensure that each user stays with the same application server throughout the session. It is recommended that data resources servers are scaled up and Web/application servers are scaled out. This recommendation is based on testing that indicates Web/e-commerce applications can handle increased load best when scaled out while database-centered applications scale up adequately for most of today’s deployments. Compaq recommends proof-of-concept testing in a non-production environment using the actual target application as a matter of best practice for all application deployments. Testing the actual target application in a production environment is the most effective way to estimate system behavior. For a detailed discussion on scaling Compaq ProLiant servers, see the white paper titled: Scaling Up and Scaling Out with Compaq ProLiant Servers and Microsoft Windows found at http://activeanswers.compaq.com/ActiveAnswers/Render/1,1027,4808-6-100-225-1,00.htm Additional information about DISA can be found at: http://activeanswers.compaq.com/ActiveAnswers/Render/1,1027,1573-6-100-225-1,00.htm.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 22
Conclusion This document has identified the technologies associated with Microsoft XML Web Services and discusses best practices for developing, deploying, consuming, securing, and managing a Web Service from a Microsoft .NET platform. This document provided information on how to develop, deploy, consume, secure, and manage a Web Service.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 23
APPENDIX A - Microsoft’s CLR The most important component of the .NET Framework is the Common Language Runtime (CLR). Its functions include: manages and executes code written in .NET languages forms the basis of the .NET architecture activates objects performs security checks on objects lays objects out in memory executes objects garbage collects objects
The CLR environment includes the following concepts: the CLR executables metadata assemblies manifests the CTS (Common Type System) the CLS (Common Language Specification)
.NET PE File .NET PE File .NET PE File
Common Runtime Language
Figure A-1. The CLR environment.
Figure A-1 shows the two portions of the .NET environment, with the bottom portion representing the CLR and the top portion representing the CLR executable or Portable Executable (PE) files which are .NET assemblies or basic units of deployable code. The CLR is the runtime engine that loads required classes, performs just-in-time compilation on needed methods, enforces security checks, and accomplishes a number of other runtime functionalities. Microsoft .NET executables are different from typical Windows executables in that they carry not only code and data, but also metadata.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 24
Metadata is machine-readable information about a resource, or "data about data." In .NET, metadata is a common mechanism or dialect that the runtime, compilers, and tools can all use. Microsoft .NET uses metadata to describe all types of machine-readable information that are used and exposed by a particular .NET assembly. In this sense, metadata describes an assembly in detail, including descriptions of its identity (a combination of an assembly name, version, culture, and public key), the types of data that it references, the types of data that it exports, and the security requirements for execution. Metadata provides enough information for any runtime, tool, or program to find out literally anything that is needed for component integration. Stated another way, any application, tool or utility that can read metadata from an assembly can make use of that assembly. Metadata provides language interoperability, an essential element to .NET, since all languages must use the same types of data in order to generate a valid .NET PE file. The .NET runtime cannot support such features as memory management, security management, memory layout, type checking, debugging, and so on without the richness of metadata. It can safely be said that there would be no .NET without metadata. The different types of runtime, tool, component or utility must expose their metadata to allow tools and programs to access them and benefit from their services. Metadata for these items is not enough. To simplify software plug-and -play and configuration or installation of the component or software, we also need metadata about the component that hosts these types of data. This leads to a discussion about .NET assemblies (deployable units) and manifests (the metadata that describes the assemblies). An assembly is a logical collection of one or more EXE or DLL files containing an application’s code and resources. An assembly also contains a manifest, which is a metadata description of the code and resources “inside” the assembly. An assembly can be a single file, either EXE or DLL. Although an assembly often resides in a single file, it can be a logical, non-physical collection of more than one file residing in the same directory. The manifest specifying the files can reside in one of the code-containing EXE or DLL files of the assembly, or it can reside in a separate EXE or DLL file that contains nothing but the manifest. Assemblies can be public or private, depending on whether they will be used by one application or several. The .NET framework allows assemblies to be shared by placing them in the global assembly cache (GAC), which is the \\winnt\assembly directory. Shared assemblies use public key cryptography to ensure that their names are unique (strong names). The public/private key algorithm also provides a check on the integrity of the assembly’s files. The .NET Framework incorporates functionality for versioning using the assembly’s metadata.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 25
APPENDIX B - Example
Overview of a B2B Web Service Demonstration This demonstration takes Microsoft’s “Learn BizTalk” procurement scenario, which ships with BizTalk Server 2000, and adds one buyer-side and two supplier-side Web Services. The main objective of the demonstration was to create a working business scenario using BizTalk Server 2000 and Web Services to automate the process. The demonstration illustrates how a business can query multiple suppliers for pricing, pass the quote through predefined business logic, and complete the purchase automatically using Microsoft .NET technologies. In this demonstration, BizTalk Server 2000 and Visual Studio .NET are used to create a fully functional procurement process, including multiple supplier quotes. The physical implementation of this demonstration is illustrated in Figure B-1. Web Services handle the initial communication and logic before the process enters BizTalk, as illustrated in Figure B-2, which uses XLANG for the logic. SOAP and XML are the standard data formats for the documents and data transfer is handled via HTTP Posts. Both ASP and ASP.NET are used to place the posts into the business message queues (MSMQ). The Learn BizTalk demo provides an excellent overview of the functionality of BizTalk server. This demonstration added logic in the XLANG schedules, to handle multiple suppliers, and added/modified the ports and channels. The Web Services were added to complete the process and create an actual Microsoft XML Web Service implementation.
Figure B-1:
Physical Implementation of Demonstration
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 26
Figure B-2: Flow of logic and communication in the demonstration
Figure B-3 illustrates the processing of the transactions in the demonstration and the transaction steps are described in the numbered steps that follow Figure B-3.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 27
Figure B-3: Flow of transactions in the demonstration
4. A user from the Buyer company accesses an internal Active Server Page (ASP), then completes and submits a Purchase Request. 5. The ASP performs an HTTP Post to an internal Web Service. This Purchase Request is sent using a SOAP envelope via HTTP. 6. The Buyer’s Web Service receives the Purchase Request, process it and sends out a Quote Request using a SOAP envelope via HTTP to the Web Service of each of the two suppliers, Supplier 1 and Supplier 2. 7. Each supplier’s Web Service processes the Quote Request and sends a “Quote Response,” again with a SOAP envelope via HTTP to the Buyer’s Web Service. 8. Once the Buyer’s Web Service receives all quotes, the Buyer’s Web Service processes the quotes and determines which supplier is quoting the lowest cost for the product(s) that the buyer wants to purchase. The Web Service then creates an XML-based Purchase Order (PO) Request that includes product, quantity, which supplier to purchase from, and other pertinent information and places it into an MSMQ Queue. 9. The Buyer’s BizTalk Server “Receive Function” pulls the XML-based PO Request into BizTalk for processing. BizTalk passes the PO Request to an XLANG schedule for the business logic to Approve or Disapprove the request and provide BizTalk the answer. If the PO Request is Disapproved, BizTalk sends an e-mail to the individual responsible for the request indicating that the PO Request has been Disapproved. If the PO Request is Approved, BizTalk sends a SOAP envelope “Purchase Order” via HTTP to the supplier determined by the Web Service. Supplier receives the Purchase Order via an Active Server Page and the ASP places the PO into an MSMQ Queue.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 28
10. The supplier’s Web Service sends an “Acknowledgement” to the Buyer’s BizTalk Server and causes the order to be shipped. 11. The supplier’s BizTalk Server pulls the Purchase Order from the MSMQ Queue for processing. After processing, the supplier’s Web Service posts an “Invoice” to the Buyer’s Receive ASP. Again, the Posting of the ASP uses a SOAP envelope and HTTP as the transport. 12. The Buyer’s Web Service processes the Invoice, sends it to Finance, which then sends a “Payment” to the supplier. These steps are illustrated, in terms of logical process flow, in Figure B-4.
Logical Process Flow Biztalk Server
Receive PO R equest Pass to End User MSM Q XLA NG Schedule U ser Input Interface M essage- R equested D ata PO R equest Internal Web Site Invoice from Biztalk Server A ccept User Supplier A pprove/ Input - H TTP Post Decline to Internal Web Internal Web Service Disapprove Service R equest .ASP Page
Create XM L PO End Request from Best Quote - W rite File to Send to M SMQ Biztalk Server Invoice Directory SOAP - D etermine Requested Company to Send Data PO
Internal Web Service Biztalk Server Determine Process Best Quote XML - R equested D ata Invoice Send PO to Send out for Company - HTTP Quotes - HTTP Post to .asp page Post to Supplier W eb Service Supplier Biztalk Server Internal Web Service Process PO through Biztalk Gather Quotes SOAP - Server - H TTP from B oth Requested XM L - PO Post Invoice to Suppliers Part and to Supplier N orthwind's .asp Quantity page
Supplier Web Service .ASP Page Produce Quotes and R eturn Them - HTTP R esponse SOA P - R eceive .asp to N orthwind Quote sends Request to MSM Q Internal W eb Information MSM Q M essage - Service PO
Figure B-4: Logical Process Flow of transaction in demonstration.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 29
Sample Web Service Processing Flow Figure B-5 illustrates a simple example of the demonstration layout that can be used to demonstrate Web Service processing flow.
Figure B-5: Basic Demonstration Layout illustrating Web Service Process Flow
The steps in this demonstration Web Service processing are as follows: 13. The client application HTTP posts a SOAP Request call to the sample Web Service containing the desired transaction name and the required parameters. The client application waits for the service response. 14. The sample Web Service initiates a connection to the database and queries the hardware unit price table for the desired hardware price quote. 15. The sample Web Service receives a response from database 16. The sample Web Service processes the database response and returns the SOAP response to the client application via the synchronous HTTP connection. These steps are shown graphically in Figure B-6.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 30
Sample Web Service Processing Diagram
Receiving Product Name from Client Application
Find the Unit Price from the Compaq Hardware Price Database
Product Name match database Record?
Yes No
Return Hardware Unit Price Return Not Found Event to the Client Application
End
Figure B-6: Web Service Processing Flow in Example
Sample Web Service Processing Input Interface
Request Format Parameters Parameter Type SOAP via HTTP POST Computer Production Name String
Sample Web Service Processing Output Interface
Response Format Parameters Parameter Type SOAP via HTTP Computer Hardware Unit Price Float (Single) Response
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 31
Files and Code Samples of Sample Process Flow
Sample Web Service WSDL file
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 32
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 33
Sample SOAP Request
POST /BogusCompaq/cpqQuote.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://tempuri.org/QuoteUnitPrice"
Sample SOAP Response
HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length
Sample Web Services Source Code
Private Function GetPrice(ByVal ProductName As String) As Single Dim cpqConnection As SqlConnection Dim cpqCommand As SqlCommand Dim cpqReader As SqlDataReader Dim cpqSQL As String Dim ConnectString As String Dim cpqResult As Single
cpqResult = -1 ConnectString = "server=localhost;uid=sa;pwd=;database=BogusCompaq"
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 34
cpqSQL = "SELECT * FROM cpqProduct WHERE (cpqProductName='" + ProductName + "')"
cpqConnection = New SqlConnection(ConnectString) cpqConnection.Open() cpqCommand = New SqlCommand(cpqSQL, cpqConnection) cpqReader = cpqCommand.ExecuteReader()
While (cpqReader.Read) cpqResult = cpqReader("cpqUnitPrice") End While
Return cpqResult End Function
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 35
APPENDIX C - System Software
System Software for Enterprise Deployments The following subsections provide useful links, arranged by DISA layer.
Web Servers
Microsoft Windows 2000 Server products. See http://www.microsoft.com/windows2000/server/default.asp and http://www.compaq.com/ActiveAnswers/ for further information on Windows 2000. Microsoft Windows 2000 Service Pack 2. Windows 2000 Service Pack 2 is available at http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/default.asp. Compaq Support Paq. See http://www.compaq.com/support/ for further information on Compaq SoftPaq support software. The Compaq Support Paq is a collection of Compaq SoftPaqs that provides support software for Compaq ProLiant server deployments. Microsoft SQL Server 2000, Enterprise Edition, Client Utilities only. See http://www.microsoft.com/sql/default.asp for further information. Microsoft MDAC (most current version). See http://www.microsoft.com/data/ for further information.
Application Servers
Microsoft Windows 2000 Advanced Server. See http://www.microsoft.com/windows2000/server/default.asp and http://www.compaq.com/ActiveAnswers/ for further information on Windows 2000 Server and Advanced Server. Microsoft Windows 2000 Service Pack 2. Windows 2000 Service Pack 2 is available at http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/default.asp. Compaq Support Paq. See http://www.compaq.com/support/ for further information on Compaq SoftPaq support software. The Compaq Support Paq is a collection of Compaq SoftPaqs that provides support software for Compaq ProLiant server deployments. Microsoft SQL Server 2000, Enterprise Edition, Client Utilities only. See http://www.microsoft.com/sql/default.asp for further information. Microsoft MDAC (most current version). See http://www.microsoft.com/data/ for further information. Microsoft Visio 2000, Standard Edition. See http://www.microsoft.com/office/visio/ for further information. Microsoft BizTalk Server 2000, Enterprise Edition. See http://www.microsoft.com/biztalk/ and http://www.compaq.com/ActiveAnswers/ for further information. Microsoft BizTalk Server 2000 Service Pack 1. This is available at http://www.microsoft.com/biztalk/downloads/updates/2000/SP1.asp.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 36
Data Resources Server
MSMQ Cluster Microsoft Windows 2000 Advanced Server. See http://www.microsoft.com/windows2000/server/default.asp and http://www.compaq.com/ActiveAnswers/ for further information on Windows 2000 Server and Advanced Server. MSMQ must be installed from the Windows 2000 Advanced Server installation media. See http://www.microsoft.com/msmq/. Microsoft Windows 2000 Service Pack 2. Windows 2000 Service Pack 2 is available at http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/default.asp. Compaq Support Paq. See http://www.compaq.com/support/ for further information on Compaq SoftPaq support software. The Compaq Support Paq is a collection of Compaq SoftPaqs that provides support software for Compaq ProLiant server deployments.
Database Cluster Microsoft Windows 2000 Advanced Server. See http://www.microsoft.com/windows2000/server/default.asp and http://www.compaq.com/ActiveAnswers/ for further information on Windows 2000 Server and Advanced Server. Microsoft Windows 2000 Service Pack 2. Windows 2000 Service Pack 2 is available at http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/default.asp. Compaq Support Paq. See http://www.compaq.com/support/ for further information on Compaq SoftPaq support software. The Compaq Support Paq is a collection of Compaq SoftPaqs that provides support software for Compaq ProLiant server deployments. Microsoft SQL Server 2000, Enterprise Edition, Database engine. See http://www.microsoft.com/sql/default.asp for further information. Microsoft MDAC (most current version). See http://www.microsoft.com/data/ for further information.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 37
APPENDIX D – References The following are recommendations helpful for the person interested in implementing Web Services. Summaries of articles, where they are provided below, are identified in quotation marks and are taken directly from the referenced article or website. Authors of articles are included below only when identified by the publishing website. Connect to each Web page using the provided links for more information on the sources of this information. A Platform for Web Services Mary Kirtland - January 2001 “Summary: This article presents an overview on the Web Services model for building applications. It includes a discussion on the definition of Web Services; the generic architecture of a Web Service and how it relates to Microsoft Windows DNA and .NET; platform requirements; and some of the tools and technologies provided by Microsoft to implement and deploy Web Services.” Web Services Essentials “Summary: This document provides an overview of individual articles on Web Services.” HOW TO: Use Data in Web Services “Summary: This article shows how Datasets, an XML-based way to represent disconnected data, can be returned from a Web service method. By exposing Datasets through a service, you can limit the database connections that your data server is experiencing.” HOW TO: Write a Simple Web Service “Summary: This article describes how to write a simple Web service, called MathService, that exposes methods for adding, subtracting, dividing, and multiplying two numbers.” Designing the Contract By Scott Seely C#: A Message Queuing Application By Carl Nolan “Summary: This article outlines a Windows service solution designed to process several message queues, focusing on the application of the Microsoft .NET Framework and C#.” Message Queuing: A Scalable, Highly Available Load-Balancing Solution By Christopher Baldwin, Carl Nolan Exposing Existing Code as a Web Service Using the .NET Framework Building Distributed Applications with .NET By Steve Kirk and Priya Dhawan “Summary: This article covers data transformations made to expose existing Microsoft Visual Basic 6.0 code as a Web Service using ASP.NET. It applies to Beta 2 of the Microsoft .NET SDK and Microsoft Visual Studio .NET.” Introducing the UDDI Software Development Kit December 2000
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 38
“Summary: This paper introduces the Microsoft UDDI SDK for interacting with the UDDI Business Registry.” .NET Framework Essentials “.NET Framework Essentials is a concise and technical overview of the new Microsoft .NET Framework. Covered here are all of the most important topics: from the underlying Common Language Run-Time (CLR) to its specialized packages for ASP.NET, Web Forms, Windows Forms, XML and data access (ADO.NET). The authors survey each of the major .NET languages, including VB.NET, C# and Managed C++.” [Source: O'Reilly & Associates] .NET Framework SDK Building Client Interfaces for .NET Web Services “Learn how to create clients to consume them and learn about the importance of proxy objects and how to create a Web browser, Windows console, and Wireless Access Protocol (WAP) clients using Microsoft Visual Studio .NET.” [Source: internet.com] Applying .NET to Web Services “O'Reilly writer Brian Jepson introduces and discusses the .NET Framework in this Web Techniques article. Microsoft's .NET represents a fresh approach to Web development and provides a rapid application development (RAD) approach to creating Web services.” [Source: O'Reilly and Associates] Monitoring in .NET Distributed Application Design “Summary: Windows Management Instrumentation (WMI) is the preferred monitoring technology on the Windows platform. This article provides an intro to WMI and discusses the monitoring process in the context of .NET applications.” Accessing Message Queues “Summary: This article describes how to use System.Messaging classes in the Microsoft .NET Framework to read and write to MSMQ queues. The information discussed in this article applies to Beta 2 of the .NET Framework and Microsoft Visual Studio .NET.” C#: A Message Queuing Service Application “Summary: This article outlines a Windows service solution designed to process several message queues, focusing on the application of the Microsoft .NET Framework and C#.” A Sneak Peek at New Services from Cold Rooster Consulting ColdStorage Sample Overview “The ColdStorage sample was created by the MSDN Architectural Samples Team as an educational tool. The main goal of the sample is to show how a company might develop both a set of XML Web services to store data as well as a rich-client application that would consume the Web services.” ColdStorage Service Design Overview “Summary: This article describes the application architecture of the XML Web services included in the ColdStorage sample service.” ColdStorage Sample Development Overview “Summary: This article provides an overview of the development of the components included with the ColdStorage sample, including two Web services and a rich client application.”
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 39
Microsoft XLANG “Automation of business processes based on Web services requires a notation for the specification of message exchange behavior among participating Web services. This document specifies such a notation. We call it XLANG. XLANG is expected to serve as the basis for automated protocol engines that can track the state of process instances and help enforce protocol correctness in message flows.”
Web Services Resources Web Services Primer “A review of the emerging XML-based Web services platform, examining the core components of SOAP, WSDL and UDDI.” [XML.com] MSDN Web Services (http://msdn.microsoft.com/webservices/) .NET 247 (http://www.dotnet247.com) WebServices.org “The vendor-neutral Web services portal - SOAP,UDDI,.NET,ONE,ebXML...” Web Services Architect (http://www.webservicesarchitect.com/) WSDL / SOAP Web Services Search Engine: SalCentral (http://www.salcentral.com/) “The world's largest brokerage for schemas, reviews and quality assurance information on Web Services. Provides a Web Services search engine.” XMethods (http://www.xmethods.com/) Xmethods is a site dedicated to promoting the development, deployment, and use of Web Services, offers (amongst other things) a directory of Web Services and a discussion forum. XMethods provides examples of SOAP-based Web services, as well as XML information, tutorials and tools. XMLBus.com (http://www.xmlbus.com/) XMLBus.com is a resource for people who are interested in Web Services and want to learn more about Web Services technology. XMLBus.com provides online tools to Browse UDDI and to dynamically test Web Services running on XMLBus.com or elsewhere on the Internet. developer.* - http://www.developerdotstar.com/index.htm DevX – http://www.devx.com/ - multi-technology site including items licensed from Fawcette Publishing O'Reilly Network .NET DevCenter: http://www.oreillynet.com/dotnet/ O'Reilly Network Web Services DevCenter: http://www.oreillynet.com/webservices/ Web Services Journal Web Services Journal (http://www.sys-con.com/webservices/) .NET Hosting - http://www.brinkster.com/ Flamenco Networks – Web Services Network - http://www.flamenconetworks.com/ IBM Webservices Developer Works (http://www.ibm.com/developer/webservices/) IBM Web Services Toolkit IBM Webservices Development Kit
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 40
UDDI Microsoft UDDI (http://uddi.microsoft.com/) Microsoft's UDDI directory, with information about UDDI (and registering for UDDI). Microsoft UDDI Directory (http://uddi.microsoft.com/visualstudio) Query the UDDI Business Registry to find companies and production Web Services. Test Microsoft UDDI Directory (http://test.uddi.microsoft.com/visualstudio) Locate test Web Services to use during development. Microsoft UDDI SDK (http://www.microsoft.com/downloads/release.asp?ReleaseID=30880) “The SDK includes both a .NET class library and a Visual Studio 6.0 library that optimize interaction with UDDI. It also includes the UDDI Developer Edition, a light-weight UDDI registry built on the .NET Framework. Now developers can build and test solutions that interact with a UDDI registry hosted locally.” Microsoft UDDI Technical Overview (http://uddi.microsoft.com/developer/tech_white_paper.doc) “Universal Discovery Description and Integration is a specification for distributed Web-based information registries of Web Services…. This paper describes the capabilities that these registries add to the World Wide Web.” Using WSDL in a UDDI Registry 1.05 “The Web Services Description Language (WSDL) is a general purpose XML language for describing the interface, protocol bindings and the deployment details of network services. WSDL complements the UDDI standard by providing a uniform way of describing the abstract interface and protocol bindings of arbitrary network services. The purpose of this document is to clarify the relationship between the two, describe how WSDL can be used to help create UDDI business service descriptions.”
SOAP SOAP 1.1 Specification World Wide Web Consortium note describing and specifying the SOAP 1.1 protocol. SOAP and .NET O'Reilly Java author Jim Farley continues his commentary on all things .NET by looking at what's cool and not so cool about SOAP. Microsoft SOAP Toolkit 2.0 SP2 A Busy Developer's Guide to SOAP 1.1 (http://www.soapware.org/bdg) By Dave Winer, Jake Savin, UserLand Software, 4/2/01. XML Today - http://www.xmltoday.com/ XSLT / XML / C# (http://www.dotnet247.com/247reference/articles/0/57.aspx) “In this article the author shows how to apply XSLT to data coming from a database in XML format.”
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 41
WSDL WSDL 1.0 (http://www-4.ibm.com/software/developer/library/w-wsdl.html) Web Services Description Language version 1.0 specification from the IBM DeveloperWorks site. WSDL 1.1 (http://www.w3.org/TR/wsdl) Web Services Description Language Web Services Description Language (WSDL) Explained “It has been argued that SOAP does not really need an interface description language to go with it. If SOAP is a standard for communicating pure content, then it needs a language for describing that content. SOAP messages do carry type information, and so SOAP allows for dynamic determination of type. But I cannot call a function correctly unless I know its name and the number of parameters and the types of each. Without WSDL, I can determine the calling syntax from documentation that must be provided, or by examining wire messages. Either way, a human will have to be involved, and so the process is prone to error. With WSDL, I can automate the generation of proxies for Web services in a truly language- and platform-independent way.” Web Services Description Language (WSDL) Explained “Using WSDL, users can automate the generation of proxies for Web services in a truly language- and platform-independent way.”
Open Source .NET .NETUnit .NETUnit is an implementation of Kent Beck and Erich Gamma's XUnit testing framework (http://www.xprogramming.com/software.htm).
CSUnit A .NET regression testing framework inspired by JUnit (www.junit.org).
Dot GNU (.GNU) The DotGNU Project is really a meta-project that will consist of between ten and twenty subprojects. The main components of DotGNU are the DotGNU Platform and the DotGNU Virtual Identities system. DotGNU will be a complete replacement for the .NET strategy - it will not be a Free Software implementation of .NET. .Net OpenSource A collection of application building blocks built on top of .NET. DotNetPCF A compound file implementation for .NET. Java.NET Halcyon Software's Java.NET project lets developers either migrate their ASP or Visual Basic code to JSP or Java, respectively, or to deploy applications on Java-based infrastructures.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 42
Mono Ximian's Mono project is an effort to create a free software (sometimes called open source) implementation of the .NET Development Framework. It will include code and tools that will enable the .NET Framework (i.e, ASP, ADO, FCL, etc.) to work with Linux and other OS. NAnt “NAnt is a .NET based build tool. In theory it is kind of like make without make's wrinkles. In practice it's a lot like Ant.” (http://jakarta.apache.org/ant/).” Nareau Project Nareau developers do not see the need to create an entire new framework, as is being done by both Mono and DotGNU. Instead, Nareau plans to make use of the many tools and protocols that already exist. Thus, the project will be built on top of Web services components like: Server software: Apache, parts of Zope, Jabber, Jakarta Client software: Mozilla, Komodo Protocols: SOAP, and Kerberos. NUnit NUnit is a .NET port of Kent Beck and Erich Gamma's JUnit (www.junit.org). NUnit is a framework for writing repeatable tests in any .NET language. OpenSMTP.NET An SMTP component written in C#. Perl.NET “Perl for .NET Research is the result of a research project, creating a native code compiler for Perl to the Microsoft .NET Framework. The status of this compiler is experimental; it also supports just a subset of the language.” Portable.NET A portable .NET implementation. It will include tools, compilers, and runtime support. For portability, the runtime will use an interpreter instead of a JIT. Python.NET “Python for .NET Research is currently an exploratory implementation of the Python language for the .NET Framework. The archive includes general documentation on the project itself, documentation and complete source code.” Sharp Egg An IRC bot written in C#. SharpDevelop A lightweight IDE for C#, ASP.NET, ADO.NET, XML, and HTML. It includes a class browser and syntax highlighting. X Marks the DOT A collection of XML-related projects written in C#.
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 43
APPENDIX E - Glossary
XML An initiative from the W3C defining an "extremely simple" dialect of SGML suitable for use on the World-Wide Web. http://www.w3.org/TR/REC-xml.html SGML Standard Generalized Markup Language (SGML). A generic markup language for representing documents. SGML is an International Standard that describes the relationship between a document's content and its structure. SGML allows document-based information to be shared and re-used across applications and computer platforms in an open, vendor-neutral format. SGML is sometimes compared to SQL, in that it enables companies to structure information in documents in an open fashion, so that it can be accessed or re-used by any SGML-aware application across multiple platforms. http://www-tei.uic.edu/orgs/tei/sgml/teip3sg/index.html XSL XSL is a language for expressing style sheets. An XSL style sheet is, like CSS, a file that describes how to display an XML document of a given type. XSL shares the functionality of and is compatible with CSS2 (although it uses a different syntax). The Extensible Stylesheet Language (XSL) CSS “Cascading Style Sheets (CSS) is a simple mechanism for adding style (e.g. fonts, colors, spacing) to Web documents.” Cascading Style Sheets ebXML Electronic Business Extensible Markup Language (ebXML) is an initiative to provide an XML-based open technical framework to enable XML to be utilized in a consistent and uniform manner for the exchange of electronic business (eb) data in application-to-application, application-to-human, and human-to-application environments — thus creating a single global electronic market. http://www.ebxml.org/specdrafts/ebXML_TA_v1.0.4.pdf SOAP - Simple Simple Object Access Protocol (SOAP) is a lightweight protocol for exchange of information in a Object Access decentralized, distributed environment. It is an XML based protocol that consists of four parts: an Protocol envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, a convention for representing remote procedure calls and responses, and a binding convention for exchanging messages using an underlying protocol. DCOM Short for Distributed Component Object Model, an extension of the Component Object Model (COM) to support objects distributed across a network. http://www.microsoft.com/Com/resources/comdocs.asp
HTTP Short for HyperText Transfer Protocol, the underlying protocol used by the World Wide Web. HTTP defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.
UDDI Universal Description, Discovery and Integration (UDDI) creates a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet, as well as an operational registry that is available today. www.uddi.org http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnuddi/html/progguide.asp Internet Internet Inter-ORB Protocol, a protocol developed by the Object Management Groupto implement Inter-ORB CORBA solutions over the World Wide Web. IIOP enables browsers and servers to exchange Protocol (IIOP) integers, arrays, and more complex objects, unlike HTTP, which only supports transmission of text. RPC Remote Procedure Call is a protocol that allows a program running on one host to cause code to be executed on another host without the programmer needing to explicitly code for this. RPC is an easy and popular paradigm for implementing the client-server model of distributed computing. An RPC is initiated by the caller (client) sending a request message to a remote system (the server) to execute a certain procedure using arguments supplied. A result message is returned to the caller. There are many variations and subtleties in various implementations, resulting in a variety of different (incompatible) RPC protocols. http://www.ja.net/documents/NetworkNews/Issue44/RPC.html
168Z-0202A-WWEN Microsoft .NET Web Services Solutions 44
WSDL Web Services Description Language WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate; however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME. CXML (Commerce XML) is a set of document type definitions (DTD) for the XML specification. cXML works as a meta-language that defines necessary information about a product. It will be used to standardize the exchange of catalog content and to define request/response processes for secure electronic transactions over the Internet. The processes include purchase orders, change orders, acknowledgments, status updates, ship notifications and payment transactions. http://www.cxml.org/home/ ADO+ “ADO+ is the . . .set of data access services for the .NET Framework. ADO+ is a natural evolution of ADO, built around n-tier development and architected with XML at its core.” Welcome to the MSDN Library
168Z-0202A-WWEN