Beat Schwegler's 2 Cents : .NET Framework

Web Services Quiz: Issue 10 - the Answer

beatsch — Tue, 15 Mar 2005 21:45:00 GMT

The correct answer to Issue 10 was already mentioned by Andrew & Mario:

Service T1 will deny access, and therefore return a HTTP status 401 error: “Access Denied”

If we want to allow the called services to impersonate the caller’s identity, we have to explicitly pass on its credentials. In the default scenario, no credentials are transmitted and therefore the called service must be enabled for “Anonymous access”. In this case, the service call executes in the context of the account that has been specified for anonymous access. However, if we want to impersonate the caller we have to disable anonymous access and enable “Integrated Windows Security”. In addition to that, we have to make sure that the proxy transmits the right credentials. We can specify this by setting the proxy’s Credential property:

t1.T1 t1 = new OrderSrv.t1.T1();

t1.Credentials = CredentialCache.DefaultCredentials;

return t1.HelloWorld();

By setting the Credentials to the DefaultCredentials the client negotiates with the server to do Kerberos and/or NTLM authentication depending on how the server is configured.

As Mario stated, there are major issues if you want to leverage impersonations in the context of web services:

The service must be able to authenticate the client credentials and must therefore be in a trust relationship with the client or its KDC
Integrated Windows authentication does not work across proxy servers or other firewall applications
Authentication is handled on the transport and not on the message level
This approach is not suitable for interoperability scenarios

So why would one use it? I see two main drivers why people are using impersonation in the context of Web Services:

They have to authorize sensitive resource access (e.g. file system or DB).
It simplifies the effort to get authentication for web service calls.

Suggested approach:

Allow “Anonymous access” but use WS-Security to authenticate Web Service calls. If the consumer and the service are within different trust-scopes, WS-Trust can be used to issue tokens.

WSE is your friend…

Link to the XSD Object Generator download site

beatsch — Sun, 13 Mar 2005 01:16:00 GMT

For all who attended my Web Services Competency Workshop in Madrid:

Here’s a link to the XSDObjectGen.exe tool.

Interested in Z#?

beatsch — Thu, 21 Oct 2004 04:20:00 GMT

A. Wöß and H. Mössenböck from the University of Linz just published the following courseware:

Compiler Construction - Concepts and Practical Application to .NET
This course builds a complete compiler for the programming language Z# (= subset of C#) that produces .NET executables. It will teach students the following skills:

Acquire the practical skills to write a simple compiler for an imperative programming language.
Understand the concepts of scanning, parsing, name management in nested scopes, and code generation.
Learn to transfer the skills also to general software engineering tasks (e.g. parsing of structured data files or argument lists)

What's wrong with rpc-literal?

beatsch — Mon, 27 Sep 2004 16:33:00 GMT

This post is part of Issue 8’s answer

To say it as clear and simple as possible: rpc style encoding is more about the service implementation than the message on the wire itself. That’s just wrong! As already discussed in this answer series, every rpc-literal message can be described using doc-literal encodings. Therefore there is no need to specify the implementation model of a service stub/proxy. The only thing that matters is the data on the wire.

The second thing that just drives me crazy about rpc-literal is the fact that there is no way to verify a message for correctness: Since we only got the schemas for the different message parts but not for the message itself it’s just not possible to validate the message on the wire. We only can verify the message if we got the service description by hand. But there is usually no support to verify a message against the <wsdl.message> at runtime.

To conclude: If you’re serious about Web Services and loosely coupled messaging, don’t use rpc-literal. Rather go for doc-literal!

How to consume an rpc-literal WS using .NET?

beatsch — Tue, 24 Aug 2004 00:26:00 GMT

This post is part of Issue 8’s answer

The previous post in this answer series discussed rpc-literal from a platform independent standpoint, where this post focuses on the consumption of such services using .NET. You may ask why consumption only? Well, rpc-literal is so bad that you won’t use it for your own services. Would you?

Coming back to the original question: One of our business partners provides us with an rpc-literal wsdl contract. How do we consume such a service using .NET?

If you’re not that familiar with .NET Web Services you may just answer: „By simply adding a Web Reference to my VS project”. Unfortunately, by doing so you’ll get an incomplete proxy containing a comment section similar to the one bellow:

// CODEGEN: The operation binding 'xxx from namespace ‘xxx' was ignored.

// The combination of style=rpc with use=literal is not supported.

The reason for this error is straight forward:.NET Fx 1.0 and 1.1 don’t support rpc-literal Web Services out of the box. However, the upcoming version of the .NET Fx (2.0) will support rpc-literal. In Fx 2.0, you can easily specify a service or a method as rpc-literal by simply applying the SoapRpcService or SoapRpcMethod attribute:

[SoapRpcService(Use = SoapBindingUse.Literal)]

[WebMethod]

public int Add(int a, int b)

If you’re using current .NET technology, the simplest approach to work with rpc-literal is to convert the rpc-literal wsdl into an equivalent doc-literal one. This is possible, because rpc-literal is a subset of doc-literal. Therefore, every rpc-literal message can be built using doc-literal bindings.

Here’s an example:

The following rpc-literal message

   <soap:body>
      <x:Add xmlns:x=“operationNS”>
       <a>200</a>
         <b>400</b>
      </x:Add>
   </soap:body>

can easily be constructed using the following schema element within a doc-literal binding :

<xsd:schema targetNamespace="operationNS"

xmlns:tns="operationNS">

<xsd:element name="Add" type="tns:AddType" />

<xsd:complexType name="AddType">

<xsd:sequence>

<xsd:element name="a" type="xsd:int" />

<xsd:element name="b" type="xsd:int" />

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

Yasser wrote a great article about the two encodings and described the conversion process from rpc-literal to document-literal.

Once you’ve converted the wsdl to doc-literal, it’s straight forward to generate a proxy or a stub using the ordinary wsdl.exe.

The last post in this answer series is going to discuss why you shouldn’t use rpc-literal. Stay tuned…

What is rpc-literal anyway?

beatsch — Fri, 13 Aug 2004 23:21:00 GMT

Although it’s a longtime ago, I want to follow up with the promised explanations for Issue 8:

Prolog: WS BP 1.0 prohibits the usage of rpc-encoded but explicitly allows rpc-literal. But what is rpc-literal anyway?

Rpc stands for remote procedure call. If you want to apply this technology in loosely coupled environments, you’ll get a problem: The caller must know the exact signature and method name of the target implementation; otherwise it won’t be able to call it. Although this is definitely not what we’re looking for within a Web Service enabled environment, nobody prevents you from doing so:

Rpc-literal Web Services use the rpc style of message assembling but support the literal way of describing the types that are passed by a procedure: In this case, literal means that there exists a schema for every parameter type but not for the message body itself. The message body gets constructed based on some simple rules:

The procedure (or method) name defines the name of the message
The different part names within <wsdl:message> are used for the argument names

Let’s have a look at the four different artifacts, the CLR signature, the wsdl message, the binding and the soap message:

A typical rpc signature for an addition request looks the following (note, there is no message):

int Add (int a, int b)

The corresponding wsdl message is named after its method and adds a part for each argument:

Within the wsdl bindings, the style is set to rpc and the soap body namespace must be defined (the namespace will be used for the top-level message elements):

<wsdl:binding name=“…" type="tns:…">

<soap:binding style=“rpc“ …>

<wsdl:operation name=“Add">

<wsdl:input name=“Add">

<soap:body namespace="operationNS" use="literal"/>

</wsdl:input>

</wsdl:operation>

</wsdl:binding>

The soap message gets assembled by using the operation name and the corresponding message parts:

<soap:body>
      <x:Add xmlns:x=“operationNS”>
         <a>200</a>
         <b>400</b>
      </x:Add>
   </soap:body>

The next post in this answer series is going to discuss how you can consume rpc-literal Web Services using .NET. Stay tuned…

"Visual Studio 2005 Team System" (aka Burton) gets its own Blog ...

beatsch — Tue, 25 May 2004 17:20:00 GMT

http://blogs.msdn.com/askburton

Security Roadshow for Developers: All Slides and Demos are Online ...

beatsch — Mon, 24 May 2004 05:11:00 GMT

Back from the road again…

The Security Roadshow for Developers was a true success. For many attendees it was the start of a long journey…

All the slides and demos can be found here

Web Services Quiz: Issue 8 - the Answer

beatsch — Mon, 24 May 2004 01:56:00 GMT

The number one problem in dealing with rpc-literal Web Services is the fact that they are unsupported on the .NET platform, yet. However, every rpc-literal message can be “built” using a doc-literal based implementations. By doing so, the .NET stub for the WSDL defined in Issue 8 may look the following:

[WebServiceBinding(Name="CalculatorSoap", Namespace="uri.test.com")]

public abstract class Issue7Service : System.Web.Services.WebService

{

[WebMethod]

[SoapDocumentMethod("uri.test.com/add",

Use=SoapBindingUse.Literal,

ParameterStyle=SoapParameterStyle.Bare)]

[return: XmlElement("AddResponse", Namespace="uri.test.com")]

public abstract AddResponse Add([XmlElement("Add", Namespace="uri.test.com")] Add addRequest);

}

[XmlType(Namespace="uri.test.com")]

public class Add

{

public AddRequestType AddRequestType;

}

[XmlType(Namespace="uri.test.com")]

public class AddRequestType

{

public int a;

public int b;

}

[XmlType(Namespace="uri.test.com")]

public class AddResponseType

{

public int c;

}

[XmlType(Namespace="uri.test.com")]

public class AddResponse

{

public AddResponseType AddResponseType;

}

The full explanation of this answer has been split into 3 different postings:

Step 1: What is rpc-literal anyway?
Step 2: How can I implement an rpc-literal contract using .NET?
Step 3: What's wrong with rpc-literal?

Web Services Quiz: Issue 8

beatsch — Sat, 15 May 2004 01:40:00 GMT

Given the following WSDL, how does your .NET proxy and stub look like?

As always, answer and explanation will follow…

Note, it’s rpc-literal …

<?xml version="1.0" encoding="utf-8"?>

<wsdl:definitions targetNamespace="uri.test.com"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:tns="uri.test.com"

xmlns="http://schemas.xmlsoap.org/wsdl/">

<wsdl:types>

<xsd:schema elementFormDefault="qualified" targetNamespace="uri.test.com">

<xsd:complexType name="AddRequestType">

<xsd:sequence>

<xsd:element minOccurs="1" maxOccurs="1" name="a" type="xsd:int" />

<xsd:element minOccurs="1" maxOccurs="1" name="b" type="xsd:int" />

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="AddResponseType">

<xsd:sequence>

<xsd:element minOccurs="1" maxOccurs="1" name="c" type="xsd:int" />

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

</wsdl:types>

<wsdl:message name="AddRequestMsg">

<wsdl:part name="AddRequest" type="tns:AddRequestType" />

</wsdl:message>

<wsdl:message name="AddResponseMsg">

<wsdl:part name="AddResponse" type="tns:AddResponseType" />

</wsdl:message>

<wsdl:portType name="CalculatorPortType">

<wsdl:operation name="Add">

<wsdl:input message="tns:AddRequestMsg" />

<wsdl:output message="tns:AddResponseMsg" />

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="CalculatorSoap" type="tns:CalculatorPortType">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="Add">

<soap:operation soapAction="uri.test.com/add"/>

<wsdl:input>

<soap:body parts="AddRequest" use="literal"/>

</wsdl:input>

<wsdl:output>

<soap:body parts="AddResponse" use="literal"/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="Issue7Service">

<wsdl:port binding="tns:CalculatorSoap" name="CalculatorPortType">

<soap:address location="http://test.com/Issue7/Issue7Service.asmx"/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

Web Services Quiz: Issue 7 - the Answer

beatsch — Sat, 15 May 2004 01:38:00 GMT

The answer to Issue 7 is the following:

<wsdl:binding name="CalculatorSoap" type="tns:CalculatorPortType">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="Add">

<soap:operation soapAction="uri.test.com/add"/>

<wsdl:input>

<soap:body parts="AddRequest" use="literal"/>

</wsdl:input>

<wsdl:output>

<soap:body parts="AddResponse" use="literal"/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

Please note that the soap binding is rpc-literal and not document/literal.

Here is the explanation why:

Because the provided WSDL messages AddRequestMsg and AddResponseMsg are referenced as types (instead as elements), only rpc bindings are possible.

<wsdl:message name="AddRequestMsg">

<wsdl:part name="AddRequest" type="tns:AddRequestType" />

</wsdl:message>

<wsdl:message name="AddResponseMsg">

<wsdl:part name="AddResponse" type="tns:AddResponseType" />

</wsdl:message>

But let’s look at the corresponding WS-I BP 1.0 rules:

R2203 An rpc-literal binding in a DESCRIPTION MUST refer, in its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the type attribute.

R2204 A document-literal binding in a DESCRIPTION MUST refer, in each of its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the element attribute.

Because the provided messages use the type attribute to define their parts, we have to define an rpc-literal binding to be compliant with the WS-I BP 1.0.

This leads me straight to Issue 8 – Dealing with rpc-literal in a.NET environment.

.NET CodeDOM Demystified - the Recording

beatsch — Sun, 09 May 2004 05:44:00 GMT

The recorded MSDN CodeDOM Webcast can be found here.

Web Services Quiz: Issue 7

beatsch — Wed, 05 May 2004 23:04:00 GMT

The following Issue arose out of several enquires. Here is the consolidated question:

How does the corresponding SOAP binding look like if you want to get a WS-I compliant WSDL?

As always, answer and explanation will follow…

<?xml version="1.0" encoding="utf-8"?>

<wsdl:definitions targetNamespace="uri.test.com"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:tns="uri.test.com"

xmlns="http://schemas.xmlsoap.org/wsdl/">

<wsdl:types>

<xsd:schema elementFormDefault="qualified" targetNamespace="uri.test.com">

<xsd:complexType name="AddRequestType">

<xsd:sequence>

<xsd:element minOccurs="1" maxOccurs="1" name="a" type="xsd:int" />

<xsd:element minOccurs="1" maxOccurs="1" name="b" type="xsd:int" />

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="AddResponseType">

<xsd:sequence>

<xsd:element minOccurs="1" maxOccurs="1" name="c" type="xsd:int" />

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

</wsdl:types>

<wsdl:message name="AddRequestMsg">

<wsdl:part name="AddRequest" type="tns:AddRequestType" />

</wsdl:message>

<wsdl:message name="AddResponseMsg">

<wsdl:part name="AddResponse" type="tns:AddResponseType" />

</wsdl:message>

<wsdl:portType name="CalculatorPortType">

<wsdl:operation name="Add">

<wsdl:input message="tns:AddRequestMsg" />

<wsdl:output message="tns:AddResponseMsg" />

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="CalculatorSoap" type="tns:CalculatorPortType">

</wsdl:binding>

</wsdl:definitions>

.NET CodeDOM Demystified - the Demos

beatsch — Tue, 04 May 2004 22:55:00 GMT

The demos are now available for download!

.NET CodeDOM Demystified - the Agenda

beatsch — Thu, 29 Apr 2004 00:48:00 GMT

For everybody interested in attending my live MSDN Webcast tomorrow, here is the agenda:

CodeDOM
- Introduction
- Assembly compilation
- Source code generation
- Source code parsing
Advanced concepts
- Template based source code generation
- On-the-fly proxy generation

I think that one of the biggest challenges in doing a live Webcast lies in the synchronization of voice and slides/demos: Both are delivered unreliable and independent of each other. To guess when the attendee gets the slide or sees the code is going to be the question…