Windows Communication Foundation (Say Goodbye for Webservices (.asmx) Stack ) .NET 3.0

What is Windows Communication Foundation?

Windows Communication Foundation (WCF – formerly Indigo) is the unification of all the technologies used to deliver distributed systems that run on the Microsoft platform. WCF is also an evolution of the recent attempts to promote service-oriented delivery on top of the ASMX stack. Microsoft has used the experiences from the industry after delivering the web service enhancements version 1.0 and 2.0 and shipped a consolidated set of features for developing distributed interoperable systems.Windows Communication Foundation (WCF) is an incremental, yet evolutionary technology that brings all the formerly distinct and separate Microsoft connectivity technologies together under a single umbrella within the System.ServiceModel namespace. Included in WCF are Web services (ASMX), the Web service Extensions
(WS*), Microsoft Message Queuing (MSMQ), Enterprise Services, COM+, and .NET Remoting.Having a single namespace that subsumes all of these into a coherent package is enormously useful, and makes designing, developing, and deploying applications that require connectivity far simpler. With WCF you won’t have to choose between implementations in a variety of different namespaces and coding types to create a connected application. Whether your application connects via loosely coupled Web services, or tightly coupled Enterprise
Services, the coding model will be consistent and the transition between different communication types will be much smoother because they will all be using the same programming namespace.

Using the Windows Communication Foundation
Let’s start with the following important observation: The current distributed systems technologies, most prominently ASP.NET Web Services (ASMX) along with the Web Service Enhancements (WSE) extensions, the Microsoft Message Queue (MSMQ), the Enterprise Services/COM+ runtime environment, and .NET Remoting are the foundation for countless successful applications. So is there anything fundamentally broken or wrong about these technologies that would prompt Microsoft to replace them all? No, except that there are too many of them.

“ABC” is the WCF mantra. “ABC” is the key to understanding how a WCF service endpoint is composed where
“A” stands for Address: Where is the service?
“B” stands for Binding: How do I talk to the service?
“C” stands for Contract: What can the service do for me?

Web services zealots who read Web Service Description Language (WSDL) descriptions at the breakfast table will easily recognize these three concepts as the three levels of abstraction expressed in WSDL. So if you live in a world full of angle brackets, you can look at it this way:

“A” stands for Address as expressed in the wsdl:service section and links wsdl:binding to a concrete service endpoint address.

“B” stands for Binding as expressed in the wsdl:binding section and binds a wsdl:portType contract description to a concrete transport, an envelope format and associated policies.

“C” stands for Contract as expressed in the wsdl:portType, wsdl:message and wsdl:type sections and describes
types, messages, message exchange patterns and operations.

“ABC” means that writing (and configuring) a WCF service is always a three-step process:

  •  You define a contract and implement it on a service
  •  You choose or define a service binding that selects a transport along with quality of service, security and
    other options
  • You deploy an endpoint for the contract by binding it (using the binding definition, hence the name) to a
    network address.

It is important to note is that these three elements are independent. A contract can support many bindings and a binding can support many contracts. A service can have many endpoints (contract bound to address) coexisting and available at the same time. So if you want to expose your service via HTTP and use SOAP 1.1 for maximum interoperability, and also want to expose it via TCP using a binary wire encoding for maximum performance, the two resulting endpoints can reside side-by-side on top of the very same service. WCF follows the “software as a service” model, where all units of functionality are defined as services. Rather than concentrating on how the communications work, developers need to focus on the service locations, how the services talk to each other, and how to describe what they do. So, for any service, you need to know the answer to these three groups of questions:
1. The Service Address. Where is the service? Is it on the internet, on a machine on my network, or on the
same machine as my process?
2. The Service Binding. How do I talk to it? Do I use SOAP? MSMQ?
3. The Service Contract. What does it do for me? What kind of data should I expect to pass to it, and what
does it return?

If you’re familiar with Web services, you probably already understand these three aspects in terms WSDL. And you’d be right. WCF takes this popular and successful methodology for defining how services work and extends it to work with the other forms of communication: Microsoft Message Queuing (MSMQ), Enterprise Services, COM+, and .NET Remoting.

WCF Fundamentals

A WCF Service is a program that exposes a collection of Endpoints. Each Endpoint is a portal for communicating
with the world.

A Client is a program that exchanges messages with one or more Endpoints. A Client may also expose an Endpoint to receive Messages from a Service in a duplex message exchange pattern. The following sections describe these fundamentals in more detail.

A Service Endpoint has an Address, a Binding and a Contract.

The Endpoint’s Address is a network address where the Endpoint resides. The EndpointAddress class represents a WCF Endpoint Address.

The Endpoint’s Binding specifies how the Endpoint communicates with the world including things like transport protocol (e.g. TCP, HTTP), encoding (e.g. text, binary), and security requirements (e.g. SSL, SOAP message security). The Binding class represents a WCF Binding.

The Endpoint’s Contract specifies what the Endpoint communicates and is essentially a collection of messages organized in operations that have basic Message Exchange Patterns (MEPs) such as one-way, duplex and request/reply. The ContractDescription class represents a WCF Contract.

The ServiceEndpoint class represents an Endpoint and has an EndpointAddress, a Binding and a ContractDescription corresponding to the Endpoint’s Address, Binding and Contract respectively .

I will write more in my next blog….wait ….

ADOMD.NET (Microsoft .NET Framework data provider )

ADOMD.NET is a Microsoft .NET Framework data provider that is designed to communicate with Microsoft SQL Server 2005 Analysis Services (SSAS). ADOMD.NET uses the XML for Analysis protocol to communicate with analytical data sources by using either TCP/IP or HTTP connections to transmit and receive SOAP requests and responses that are compliant with the XML for Analysis specification. Commands can be sent in Multidimensional Expressions (MDX), Data Mining Extensions (DMX), Analysis Services Scripting Language (ASSL), or even a limited syntax of SQL, and may not return a result. Analytical data, key performance indicators (KPIs), and mining models can be queried and manipulated by using the ADOMD.NET object model. By using ADOMD.NET, you can also view and work with metadata either by retrieving OLE DB-compliant schema rowsets or by using the ADOMD.NET object model.

ADOMD.NET Architecture 

Microsoft SQL Server 2005 Analysis Services (SSAS) uses both server and client components to supply online analytical processing (OLAP) and data mining functionality for business intelligence applications:

The server component of Analysis Services is implemented as a Microsoft Windows service. SQL Server 2005 Analysis Services supports multiple instances on the same computer, with each instance of Analysis Services implemented as a separate instance of the Windows service.

Clients communicate with Analysis Services using the public standard XML for Analysis (XMLA), a SOAP-based protocol for issuing commands and receiving responses, exposed as a Web service. Client object models are also provided over XMLA, and can be accessed either by using a managed provider, such as ADOMD.NET, or a native OLE DB provider.

Query commands can be issued using the following languages: SQL; Multidimensional Expressions (MDX), an industry standard query language for analysis; or Data Mining Extensions (DMX), an industry standard query language oriented toward data mining. Analysis Services Scripting Language (ASSL) can also be used to manage Analysis Services database objects

Analysis Services Concepts

Microsoft SQL Server 2005 Analysis Services (SSAS) provides online analytical processing (OLAP) and data mining functionality for business intelligence solutions. Before designing a business intelligence solution using Analysis Services, you should familiarize yourself with the OLAP and data mining concepts required for a successful solution.

Analysis Services combines the best aspects of traditional OLAP-based analysis and relational-based reporting by enabling developers to define a single data model, called a Unified Dimensional Model (UDM) over one or more physical data sources. All end user queries from OLAP, reporting, and custom BI applications access the data in the underlying data sources through the UDM, which provides a single business view of this relational data.

Analysis Services provides a rich set of data mining algorithms to enable business users to mine their data looking for specific patterns and trends. These data mining algorithms can be used to analyze data through a UDM or directly from a physical data store.

ADOMD.NET source code for querying KPIs in Analysis Services 2005 in ASP.NET

One of the more publicized features of Analysis Services 2005 is the intrinsic support for the KPIs . KPIs are defined by cube designer and any client application can programmatically get the rich metadata about them (i.e. Goals, Trends, Graphics etc) and query them. Support for programmability of KPIs is built-in into all layers of Analysis Services APIs – schema rowset in XML for Analysis, OLEDB for OLAP, MDX functions, objects in ADOMD.NET object model etc. Another interesting thing about that source code is that it makes use of parametric queries in ADOMD.NET. Parametric queries are something that application developers have asked for and now Analysis Services 2005 supports them. One additional comment about Olivier’s code – when he wrote it, the MDX functions KPIValue, KPIGoal, KPITrend etc didn’t accept KPI name as a string, and a result he was forced to use StrToMember functions in the MDX query generation. In the more recent Yukon builds it changed, so the code now will be simplified – i.e. the following snippet

 myKPICommand.CommandText = @"     SELECT { strtomember(@Value), strtomember(@Goal), strtomember(@Status), strtomember(@Trend) }      ON COLUMNS FROM [" +myCubeDef.Name + "]";  myKPICommand.Parameters.Clear();  myKPICommand.Parameters.Add(new AdomdParameter("Value", "KPIValue([" + k.Name + "])"));  myKPICommand.Parameters.Add(new AdomdParameter("Goal", "KPIGoal([" + k.Name + "])"));  myKPICommand.Parameters.Add(new AdomdParameter("Status", "KPIStatus([" + k.Name + "])"));  myKPICommand.Parameters.Add(new AdomdParameter("Trend", "KPITrend([" + k.Name + "])"));

would become

 myKPICommand.CommandText = @"     SELECT { KPIValue(@Value), KPIGoal(@Goal), KPIStatus(@Status), KPITrend(@Trend) }      ON COLUMNS FROM [" +myCubeDef.Name + "]";  myKPICommand.Parameters.Clear();  myKPICommand.Parameters.Add(new AdomdParameter("Value", k.Name));  myKPICommand.Parameters.Add(new AdomdParameter("Goal",  k.Name));  myKPICommand.Parameters.Add(new AdomdParameter("Status",k.Name));   myKPICommand.Parameters.Add(new AdomdParameter("Trend", k.Name)); 

Finally, below is the sample screenshot of how it would look like: