Thursday, December 27, 2007

How do we use a Web Service?

This is how the Web Service releases information. We need to write clients to extract the information from the XML document. Theses clients could be
A Web page
A console / Windows application
A Wireless Markup Language (WML) / WMLScript to interact with mobile phones
A Palm / Win CE application to use on Personal Digital Assistants (PDAs). I will explain this process in the

You can also call the Web Service directly using the HTTP GET method. In this case we will not be going through the above Web page and clicking the Invoke button. The syntax for directly calling the Web Service using HTTP GET is
Therefore, the call for our Web Service will be
This will produce the same result as clicking the Invoke button.
Now we know how to create a Web Service and use it. But the work is half done. How will our clients find our Web Service? Is there any way to search for our Web Service on the Internet? Is there a Web crawler or a Yahoo search engine for Web Services? In order to answer these questions we need to create a "discovery" file for our Web Service.

Creating a Discovery file
Web Service discovery is the process of locating and interrogating Web Service descriptions, which is a preliminary step for accessing a Web Service. It is through the discovery process that Web Service clients learn that a Web Service exists, what its capabilities are, and how to properly interact with it. Discovery file is a XML document with a .DISCO extension. It is not compulsory to create a discovery file for each Web Service. Here is a sample discovery file for our securities Web Service.

We can name this file "SampleService.disco" and save it to the same directory as the Web Service. If we are creating any other Web Services under the "/work/aspx" directory, it is wise to enable "dynamic discovery." Dynamic discovery will scan for all the *.DISCO files in all the subdirectories of "/work/aspx" automatically.

An example of an active discovery file can be found at By analyzing the discovery file we can find where the Web Services reside in the system. Unfortunately both these methods require you to know the exact URL of the discovery file. If we cannot find the discovery file, we will not be able to locate the Web Services. Universal Description, Discovery, and Integration (UDDI) describes mechanisms to advertise existing Web Services. This technology is still at the infant stage. UDDI is an open, Internet-based specification designed to be the building block that will enable businesses to quickly, easily, and dynamically find and transact business with one another using their preferred applications. A reference site for UDDI is
There have been a lot of Web Services written by developers. is one of the sites that has an index of Web Services. Some developers are building WSDL search engines to find Web Services on the Web.

Deploying a Web Service
Deploying the Web Services from development to staging or production is very simple. Similar to ASP.NET applications, just copy the .ASMX file and the .DISCO files to the appropriate directories, and you are in business.

The future of the Web Services
The future looks bright for the Web Service technology. Microsoft is not alone in the race for Web Service technology. Sun and IBM are very interested. There are SOAP toolkits available for Apache and Java Web servers. I believe Web Services needs a bit of work, especially the Web Service discovery process. It is still very primitive.
On a positive note, Web Services have the potential to introduce new concepts to the Web. One I refer to as "pay per view" architecture. Similar to pay-TV, we can build Web sites that can generate revenue for each request a user sends (as opposed to a flat, monthly subscription). In order to get some data, we can sometimes pay a small fee. Commercially this could be handy for a lot of people.

Online newspaper sites can publish a 10-year-old article with a $2 "pay per view" structure.
Stock market portals can itemize every user portfolio for every single stock quote and build pricing and discount structures. And the list goes on ...
On a very optimistic note, Web Services can be described as the "plug and play" building blocks of enterprise Business to Business (B2B) Web solutions.
Appendix A


This method call will get the company name and the price for a given security code.

This method call will get the company name and the price for a given security code.

This method call will get the company name and the price for a given security code.

elementFormDefault="qualified" xmlns="">

Creating a .NET Web Service

Microsoft .NET marketing has created a huge hype about its Web Services. This is the first of two articles on Web Services. Here we will create a .NET Web Service using C#. We will look closely at the Discovery protocol, UDDI, and the future of the Web Services. In the next article, we will concentrate on consuming existing Web Services on multiple platforms (i.e., Web, WAP-enabled mobile phones, and windows applications).

Why do we need Web Services?
After buying something over the Internet, you may have wondered about the delivery status. Calling the delivery company consumes your time, and it's also not a value-added activity for the delivery company. To eliminate this scenario the delivery company needs to expose the delivery information without compromising its security. Enterprise security architecture can be very sophisticated. What if we can just use port 80 (the Web server port) and expose the information through the Web server? Still, we have to build a whole new Web application to extract data from the core business applications. This will cost the delivery company money. All the company wants is to expose the delivery status and concentrate on its core business. This is where Web Services come in.

What is a Web Service?
Web Services are a very general model for building applications and can be implemented for any operation system that supports communication over the Internet. Web Services use the best of component-based development and the Web. Component-base object models like Distributed Component Object Model (DCOM), Remote Method Invocation (RMI), and Internet Inter-Orb Protocol (IIOP) have been around for some time. Unfortunately all these models depend on an object-model-specific protocol. Web Services extend these models a bit further to communicate with the Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML) to eradicate the object-model-specific protocol barrier (see Figure 1).
Web Services basically uses Hypertext Transfer Protocol (HTTP) and SOAP to make business data available on the Web. It exposes the business objects (COM objects, Java Beans, etc.) to SOAP calls over HTTP and executes remote function calls. The Web Service consumers are able to invoke method calls on remote objects by using SOAP and HTTP over the Web.

How is the user at Location A aware of the semantics of the Web Service at Location B? This question is answered by conforming to a common standard. Service Description Language (SDL), SOAP Contract Language (SCL) and Network Accessible Specification Language (NASSL) are some XML-like languages built for this purpose. However, IBM and Microsoft recently agreed on the Web Service Description Language (WSDL) as the Web Service standard.
The structure of the Web Service components is exposed using this Web Service Description Language. WSDL 1.1 is a XML document describing the attributes and interfaces of the Web Service. The new specification is available at

The task ahead
The best way to learn about Web Services is to create one. We all are familiar with stock quote services. The NASDAQ, Dow Jones, and Australian Stock Exchange are famous examples. All of them provide an interface to enter a company code and receive the latest stock price. We will try to replicate the same functionality.
The input parameters for our securities Web service will be a company code. The Web service will extract the price feed by executing middle-tier business logic functions. The business logic functions are kept to a bare minimum to concentrate on the Web service features.

Tools to create a Web Service
The core software component to implement this application will be MS .NET Framework SDK, which is currently in beta. You can download a version from Microsoft. I used Windows 2000 Advance Server on a Pentium III with 300 MB of RAM.
The preferred Integration Development Environment (IDE) to create Web Services is Visual Studio .NET. However, you can easily use any text editor (WordPad, Notepad, Visual Studio 6.0) to create a Web Service file.

I assume you are familiar with the following concepts:
Basic knowledge of .NET platform
Basic knowledge of C#
Basic knowledge of object-oriented concepts
Creating a Web Service
We are going to use C# to create a Web Service called "SecurityWebService." A Web Service file will have an .ASMX file extension. (as opposed to an .ASPX file extension of a ASP.NET file).

The first line of the file will look like
<%@ WebService Language="C#" class="SecurityWebService" %>
This line will instruct the compiler to run on Web Service mode and the name of the C# class. We also need to access the Web Service namespace. It is also a good practice to add a reference to the System namespace.
using System;
using System.Web.Services;
The SecurityWebService class should inherit the functionality of the Web Services class. Therefore, we put the following line of code:
public class SecurityWebService : WebService
Now we can use our object-oriented programming skills to build a class. C# classes are very similar to C++ or Java classes. It will be a walk in the park to create a C# class for anyone with either language-coding skills.
Dot-net Web Services are intelligent enough to cast basic data types. Therefore, if we return "int," "float," or "string" data types, it can convert them to standard XML output. Unfortunately, in most cases we need get a collection of data regarding a single entity. Let's take an example.
Our SecurityWebService stock quotes service requires the user to enter a company code, and it will deliver the full company name and the current stock price. Therefore, we have three pieces of information for a single company:
Company code (data type - string)
Company name (data type - string)
Price (data type - Double) We need to extract all this data when we are referring to a single stock quote. There are several ways of doing this. The best way could be to bundle them in an enumerated data type. We can use "structs" in C# to do this, which is very similar to C++ structs.
public struct SecurityInfo
public string Code;
public string CompanyName;
public double Price;
Now we have all the building blocks to create our Web Service. Therefore, our code will look like.
<%@ WebService Language="C#" class="SecurityWebService" %>
using System;
using System.Web.Services;
public struct SecurityInfo
public string Code;
public string CompanyName;
public double Price;
public class SecurityWebService : WebService
private SecurityInfo Security;

public SecurityWebService()
Security.Code = "";
Security.CompanyName = "";
Security.Price = 0;
private void AssignValues(string Code)
// This is where you use your business components.
// Method calls on Business components are used to populate the data.
// For demonstration purposes, I will add a string to the Code and
// use a random number generator to create the price feed.

Security.Code = Code;
Security.CompanyName = Code + " Pty Ltd";
Random RandomNumber = new System.Random();
Security.Price = double.Parse(new System.Random(RandomNumber.Next(1,10)).NextDouble().ToString("##.##"));
[WebMethod(Description="This method call will get the company name and the price for a given security code.",EnableSession=false)]
public SecurityInfo GetSecurityInfo(string Code)
SecurityInfo SecurityDetails = new SecurityInfo();
SecurityDetails.Code = Security.Code;
SecurityDetails.CompanyName = Security.CompanyName;
SecurityDetails.Price = Security.Price;
return SecurityDetails;
Remember, this Web Service can be accessed through HTTP for any use. We may be referring to sensitive business data in the code and wouldn't want it to fall into the wrong hands. The solution is to protect the business logic function and only have access to the presentation functions. This is achieved by using the keyword "[Web Method]" in C#. Let's look at the function headers of our code.
public SecurityInfo GetSecurityInfo(string Code)
This function is exposed to the public. The "description" tag can be used to describe the Web Service functionality. Since we will not be storing any session data, we will disable the session state.
private void AssignValues(string Code)
This is a business logic function that should not be publicly available. We do not want our sensitive business information publicly available on the Web. (Note:- Even if you change the "private" keyword to "public," it will still not be publicly available. You guessed it, the keyword "[Web Method]" is not used.)
We can use the business logic in this function to get the newest stock price quote. For the purpose of this article I have added some text to the company code to create the company name. The price value is generated using a random number generator.
We may save this file as "SampleService.asmx" under an Internet Information Service (IIS)-controlled directory. I have saved it under a virtual directory called "/work/aspx." I'll bring it up on a Web browser.

This is a Web page rendered by the .NET Framework. We did not create this page. (The page is generated automatically by the system. I did not write any code to render it on the browser. This graphic is a by-product of the previous code.) This ready-to-use functionality is quite adequate for a simple Web Service. The presentation of this page can be changed very easily by using ASP.NET pagelets and config.web files. A very good example can be found at
Notice a link to "SDL Contract." (Even if we are using WSDL, .NET Beta still refers to SDL. Hopefully this will be rectified in the next version). This is the description of the Web Service to create a proxy object. (I will explain this in the next article.) This basically gives an overview of the Web Service and it's public interface. If you look closely, you will only see the "Web-only" methods being illustrated. All the private functions and attributes are not described in the SDL contract. The SDL contract for the SecurityWebService can be found in Appendix A.

Thursday, December 20, 2007

XML Web Services Overview

An XML Web service is a programmable entity that provides a particular element of functionality, such as application logic, and is accessible to any number of potentially disparate systems using ubiquitous Internet standards, such as XML and HTTP. XML Web services depend heavily upon the broad acceptance of XML and other Internet standards to create an infrastructure that supports application interoperability at a level that solves many of the problems that previously hindered such attempts.
An XML Web service can be used internally by a single application or exposed externally over the Internet for use by any number of applications. Because it is accessible through a standard interface, an XML Web service allows heterogeneous systems to work together as a single web of computation.
Instead of pursuing the generic capabilities of code portability, XML Web services provide a viable solution for enabling data and system interoperability. XML Web services use XML-based messaging as a fundamental means of data communication to help bridge the differences that exist between systems that use incongruent component models, operating systems, and programming languages. Developers can create applications that weave together XML Web services from a variety of sources in much the same way that developers traditionally use components when creating a distributed application.
One of the core characteristics of an XML Web service is the high degree of abstraction that exists between the implementation and the consumption of a service. By using XML-based messaging as the mechanism by which the service is created and accessed, both the XML Web service client and the XML Web service provider are freed from needing any knowledge of each other beyond inputs, outputs, and location.
XML Web services are enabling a new era of distributed application development. It is no longer a matter of object model wars or programming language beauty contests. When systems are tightly coupled using proprietary infrastructures, this is done at the expense of application interoperability. XML Web services deliver interoperability on an entirely new level that negates such counterproductive rivalries. As the next revolutionary advancement of the Internet, XML Web services will become the fundamental structure that links together all computing devices.

Windows Communication Foundation

WCF is Microsoft's unified programming model and runtime for building Web services applications with managed code. It extends the .NET Framework with functionality to build secure, reliable, and transacted Web services that interoperate across platforms.
WCF is built from the ground-up to combine and extend the capabilities of existing Microsoft distributed systems technologies, including Enterprise Services, System.Messaging, .NET Remoting, ASMX, and WSE, to deliver a unified development experience based on Web services.
WCF supports the WS-* architecture, enabling the development of interoperable Web services that incorporate end-to-end security, reliability and transaction support:

Messaging: XML, SOAP, WS-Addressing, and MTOM
WCF supports both Representational State Transfer (REST) and SOAP-based Web services. WCF also supports WS-Addressing, which defines additions to the SOAP header for addressing SOAP messages. This frees SOAP from relying on the underlying transport protocol for addressing information. MTOM defines an optimized transmission format for attachments in SOAP messages based on the XML-binary Optimized Packaging (XOP) specification.

Metadata: WSDL, WS-MetadataExchange, WS-Policy, and WS-SecurityPolicy
WCF supports the Web Services Description Language (WSDL), which defines a standard language for specifying services and various aspects of how those services can be used. WCF also supports WS-Policy and WS-SecurityPolicy to describe more dynamic aspects of a service's behavior that cannot be expressed in WSDL, such as a preferred security option. Lastly, WCF's support for WS-MetadataExchange means that clients can request service metadata, such as the WSDL and policies for a service, via SOAP.

Security: WS-Security, WS-Trust, and WS-SecureConversation
WCF supports both transport-level security via SSL and message-level security, by implementing WS-Security, WS-Trust, and WS-SecureConversation. These specifications define additions to SOAP for message-level protection, integrity, authentication, and identity

federation. Message-level security is not limited to a single type of credential and gives developers more granular control over which message parts should be secured.

Reliability: WS-ReliableMessaging

WCF supports WS-ReliableMessaging, which defines additions to the SOAP header that
reliable end-to-end communication, even when multiple SOAP intermediaries are traversed. WS-ReliableMessaging can guarantee that a message arrives, that it arrives exactly once and that it arrives in order.

Transactions: WS-Coordination, WS-AtomicTransaction

WCF supports WS-Coordination and WS-AtomicTransaction, enabling two-phase commit

transactions over SOAP-based exchanges.

In addition to implementing the WS-* architecture, WCF also provides opportunities for new messaging scenarios with support for TCP, named pipes, P2P and custom transports. More flexibility is also available around hosting Web services. Windows Forms applications, Windows Presentation Foundation applications, ASP.NET applications, console applications, Windows services and COM+ services can all easily host Web services endpoints over different transports. WCF also has many options for digitally signing and encrypting messages, including the following token support: Kerberos, X.509, Username, and Security Assertion Markup Language (SAML).

Windows Workflow Foundation
Another new feature in the .NET Framework 3.0 used for the development of Web services is WF. WF is the programming model, engine, and tools for quickly building workflow-enabled applications on Windows. It provides a common framework for building workflows into Windows applications, whether those workflows coordinate interactions among software, people, or both.
WCF and WF are complementary building blocks for distributed application development. Workflows can drive the business process for a given service. Similarly, workflows in turn often need to interact with services to carry out a business process. As such, WCF and WF can be used to create workflow-enabled services and service-enabled workflows.
WF ships with a base activity library that includes activities for consuming and exposing services. This means that developers can create service-enabled workflows directly from within the workflow designer. Because WF provides native support for hosting and consuming services, developers can easily create composite applications that invoke other business logic.

Web Services Enhancements

While Visual Studio and the .NET Framework 2.0 provide support for the development of basic Web services, customers in recent years have required advanced Web services functionality, including end-to-end security, routing and message attachments. Web Services Enhancements (WSE) 3.0 is a fully supported extension of the .NET Framework 2.0 and add-on to Visual Studio 2005 for building secure Web services. Released in November 2005 to coincide with the release of Visual Studio 2005, WSE 3.0 implements the latest industry-supported WS-* specifications.
Now that the WS-Security family of specifications has, to a large extent, solidified, the main goal for WSE 3.0 is to provide developers with the first complete implementation of these security specifications. As such, WSE 3.0 supports the following WS-* specifications (see Appendix for versioning information):


The focus on security was also one of the reasons why WSE 3.0 supports MTOM. Securing attachments over Direct Internet Message Encapsulation (DIME) requires transport-level security, whereas MTOM attachments can be secured by using either transport- or message-level security. As a result, developers can secure Web services attachments by taking advantage of some of the benefits of message-level security, such as end-to-end security and support for different credential types.
WSE 3.0 also introduced a set of "turnkey" security scenarios. These scenarios are high-level security building blocks that allow developers to concentrate on the business logic of a service in the knowledge that the underlying Web services communication is secure. The new configuration editor has also made creating and maintaining WSE policy files much easier. A GUI wizard creates and configures turnkey scenarios, without the developer having to resort to the XML representation of the policy file. WSE 3.0 also defines security sessions via policy, such that any given service can also act as a Security Token Service (STS).

One of the main objectives of the WSE 3.0 release is to provide a path to WCF, the unified programming model and runtime for building secure, reliable and transacted Web services. WSE 3.0 offers interoperability with WCF when using the turnkey security scenarios and also provides some programming model parity with WCF.

.NET Framework 3.0
In parallel to the development of WSE, Microsoft has been developing the .NET Framework 3.0, its next-generation managed code programming model for building applications on the Windows platform. The .NET Framework 3.0 enables developers to create visually stunning, connected, and workflow-enabled applications. It will ship as a core part of Windows Vista and will also be available on Windows XP and Windows Server 2003 through the .NET Framework 3.0 Runtime Components. The main components of the .NET Framework 3.0 for building and leveraging Web services are WCF, the Windows Workflow Foundation (WF) and Windows CardSpace.

Visual Studio 2005 and the .NET Framework 2.0

The .NET Framework 2.0 is Microsoft's managed code programming model and runtime for building applications on the Windows platform. Visual Studio is the professional development environment for building these applications. Together, Visual Studio and the .NET Framework 2.0 are designed to improve developer productivity and increase application reliability and security by providing a fully managed application environment. Developers can build high-performance, multi-tier applications for Windows and the Web, and use the .NET Compact Framework to build smart device software for mobile devices.
The .NET Framework provides Web services support that enables the more than 3.5 million .NET developers to develop, discover, debug, deploy, and consume Web services using any of the more than 20 programming languages supported on .NET. Furthermore, the .NET Framework supports WS-I Basic Profile for cross-platform interoperability. This allows .NET applications to consume and expose Web services that interoperate with virtually any application, regardless of programming language or platform.
Visual Studio's "Add Web Reference" dialog box automatically generates proxy code for WSDL-defined Web services, enabling consumption of Web services in Windows, Web, Mobile and Office-based applications.

Visual Studio also makes it easy for developers to publish and locate Web services in UDDI. From the start page of Visual Studio, developers can publish information about their Web Services directly to UDDI. As developers create new services, they can make them known across the enterprise directly from Visual Studio. By connecting to UDDI through the "Add Web Reference" dialog box, a developer may locate available Web Services.

Visual Studio also supports unit testing and load testing of Web services. Web services operations can be called directly from unit tests, much like local code. In addition, Visual Studio provides attributes and methods specifically for testing Web services.
Lastly, Visual Studio Tools for Office (VSTO) brings the power of Visual Studio and the .NET Framework 2.0 to business solutions built on Word and Excel. All Web services functionality offered by the .NET Framework can be exposed through Word and Excel solutions. As a result, developers can expose, consume, manage, and debug Web services within these solutions.

Visual Studio Team System
Visual Studio Team System (VSTS) expands the Visual Studio product line to include new software lifecycle tools for operations managers, architects, testers, project managers, and developers. Released in November 2005, VSTS reduces the complexity of delivering distributed applications and facilitates communication among members of a software team.
For developers building Web services-enabled software, VSTS extends the core capabilities of Visual Studio 2005, enabling architects to work in teams to visually design collections of Web services and validate a distributed application's architectural design against the requirements of the deployment environment. Developers can define and modify Web methods for ASMX Web services graphically, alleviating the need to manually edit configuration files to specify Web services configuration information. VSTS also gives IT Professionals the tools to graphically specify Web services settings and constraints, such as authentication and security requirements.
VSTS includes Visual Studio Team Test (TT), an integrated Visual Studio component that enables code generation of test method stubs, code coverage analysis and running of tests inside the IDE. This functionality is useful for Web services developers that want to perform regression tests and performance tests. Since Web services generally expose a Web page for manual invocation, one can also use the integrated Web testing recorder to quickly record a series of Web services tests. Once activities against the target Web site are recorded, test code is generated and can be extended with further customization.
Lastly, Visual Studio Team Foundation Server (a part of VSTS) is the team collaboration server providing functionality such as version control, work item tracking, and enterprise project management for VSTS clients. Partners can extend Team Foundation Server through a set of Web services.

Vertical Web Services Standards

The agreement on horizontal Web service standards, such as XML, SOAP, and the WS-* architecture created the foundation for the emergence of vertical Web services standards. Microsoft has played an active role in the creation of these standards, driving over a dozen vertical standards in the education, health care, finance, automotive, and telecommunication industries through working relationships with the following standards bodies:
Association for Cooperative Operations Research and Development (ACORD)
Association for Retail Industry Standards (ARTS)
Automotive Industry Action Group (AIAG)
Clinical Data Interchange Standards Consortium (CDISC)
Continental Automated Buildings Association (CABA)
Distributed Management Task Force (DMTF)
EAN International and the Unified Code Council (EAN.UCC)
European Forum for Electronic Business (EEMA)
Financial Information eXchange (FIX/FPL)
Health Level Seven (HL7)
Human Resources XML (HR-XML)
IMS Global Learning Consortium (IMS)
Interactive Financial eXchange Forum (IFX)
OPC Foundation (OPC)
Open Financial Exchange Consortium (OFX Consortium)
Open Travel Alliance (OTA)
Schools Interoperability Framework (SIF)
Society for Worldwide Interbank Financial Telecommunications (SWIFT)
TeleManagement Forum (TM Forum)

Highlights of Microsoft's current working relationships with vertical standards bodies include:

Automotive Industry Action Group (AIAG)—AIAG is an association of companies involved in the automotive industry charged with developing standards for the automotive supply chain. Microsoft is a sponsoring board member. It co-sponsored a project to define the functional requirements and recommended guidance needed to drive service-oriented architectures (SOA) for next-generation automotive supply chain scenarios leveraging Web services.
Distributed Management Task Force (DMTF)—DMTF is an industry organization leading the development of management standards such as WS-Management. Microsoft co-founded this organization and is currently a board member.

EPCglobal—EPCglobal leads the development of industry-driven standards for the Electronic Product Code (EPC) to support the use of Radio Frequency Identification (RFID) in trading networks. Microsoft is participating in the Reader Protocol and Reader Management working groups of EPC Global Software Action Group. Microsoft has also submitted XML message formats for the Reader Protocol specification and recently made contributions to the Reader Management specification.

Health Level Seven (HL7)—HL7 is one of several American National Standards Institute (ANSI)–accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Microsoft has been driving the submission of three Web services specifications (WS-Addressing, WS-Security and WS-ReliableMessaging) as an update of the HL7 Web Services Basic Profile.

IMS Global Learning Consortium—The IMS Global Learning Consortium develops standards for learning technology and several IMS specifications have become worldwide de facto standards for delivering learning products and services. Microsoft is a member of the Technical Board, helping IMS define and deliver e-Learning standards with prescriptive guidance for WS-Security, Addressing and MTOM-based attachments.

Open Financial Exchange Consortium—The OFX Consortium leads the development of standards for the electronic exchange of financial data. Over 2000 banks and brokerage firms as well as major payroll processing companies use OFX. Microsoft is co-founder of the OFX Consortium and is currently working on OFX 2.0 extensions.

RosettaNet—RosettaNet is a global standards organization that promotes collaborative commerce. Billions of dollars are transacted each year using RosettaNet standards. Microsoft currently hold seats on the Executive and Architectural Advisory Councils, driving RosettaNet's next-generation architectural specifications and integration framework based on Web services.

TeleManagement Forum—The TM Forum is a global standards body for communications services, contributing to the Information and Communications Services (ICS) industry for over 15 years. Microsoft has been driving the creation of a specification for enabling Operations/Business Support Systems (OSS/BSS) functions to be exposed as Web services.