10 – 12 APRIL 2005 Riyadh, Saudi Arabia

Visual Studio 2005 :

New Features for the Web Services
Developer
Malek Kemmou
CEO Arrabeta Consulting
Microsoft Regional Director for Middle East & Africa
Agenda

Why do we use Web Services ?

Better Interop
Basic Profile 1.1
Nillable Types support
Code Driven vs. Contract Driven
Visual Studio 2005 new features
Interfaces
Serialization
Event Based Asynchronous Calls
Team System Wsdl import
Team System EndPoint Design
Why do we use Web Services Today ?

Interoperability:
Standard based, strong multi-vendor support
Loose coupling:
Share schema, not class
Self describing, discovery
Self containing (no state) ?
Service Orientation
RPC vs. Message Approach

Client Service

Transport
Obj Obj

Serialize Deserialize
Both source and destination must understand the
object
Client Service

Transport

Create Message Interpret Message

Source and destination may see
message differently
Interoperability issues today

All vendors support Web Services but:

RPC vs Document, Encoded vs Literal
Developer uses OOP, tools handle serialization
Nillable types issues
Array serialization takes different forms
WSDL or SOAP interpretation differences
Usually solved by crafting non ambiguous and
interoperable WSDL
Basic Profile 1.1

Defined by WS-I (Web Services Interoperability

organization)
Backed by all vendors
Defines a subset of HTTP, SOAP and WSDL
that “guarantees” interoperability
As long as both sides are conformant
Basic Profile conformance = better interop
Basic Profile Conformance

By Default, Web Services generated by VS2005

are conformant
Conformance Claims through attributes
Upgrading current Web Services
VS2005 will issue warnings if the service is not
conformant
On the client, VS issues warnings if WSDL is not
conformant
Demo

Building BP conformant Web Services

Nillable Types

Example:
J2EE developer writes method
public java.util.Date getServerDate();
Method exposed by a web service. Return type
converts to :
<s:element name="getServerDateResult” type=“s:dateTime” nillable=“true” />

How do you consume it on a .Net Client ?

Nillable Value types

Nillable value types through generics

Nullable<T>
Generates “nillable=true” in Schema
Valuable for consuming non .Net Web Services,
or conforming to a schema crafted to satisfy
specific business requirement
Demo

Nillable types support

Two approaches to Contract

Code Driven
Develop functionality
Decide on operations to expose
Let the ASMX engine do the pluming for me
Generate Schemas for my types
Generate WSDL for my services

Contract Driven
Design Contract : Design/Write XSDs and WSDL
Generate types and Interfaces
Implement the Interfaces in classes
Two approaches to Contract

Both approaches end up with Contract

Both Qualify for creating Web Services
Require different skills
May have different interoperability and loose
coupling implications
Two approaches to Contract

Code Driven Contract Driven

Fast development, Total Control over
Building on current Contract
Object Oriented Skills Better Loose Coupling
Loose coupling requires Better Interoperability
discipline
Need for specific skills
May lead to
Interoperability issues
Difficult to have forward
compatibility
When to use each approach

Code Driven Contract Driven

Simple messages
Two sides agree on
Basic types, careful with
nillable types, arrays &
contract
DateTime Complex messages
Internal development
Interoperability is of great
no interop, test based
validation of contract concern
Single sided offering
(Internet Web Service
offerings)
Require .Net
Or special care for
interoperability (difficult
task)
Interfaces

An interface is a class without implementation

Defines method and property signatures
Isolates exposed functionality from
implementation
Object Oriented approximation of Contract
Web Service Interfaces in VS2005

Attributes in the interface

WebServiceBinding, WebMethod,
SOAPDocumentMethod …etc
Implementing Class inherits the attributes
A Class can implement multiple interfaces
Generated WSDL document reflects the interfaces
Each interface goes into a separate Binding
Better control over what goes into WSDL and how
Demo

Using Web Service Interfaces

Custom Serialization

In .Net Framework 1.x, undocumented

IXMLSerializable
Nick named by some : “ISupportDataSet”
.Net Framework 2 offers IXMLSerizable
Easy to use extensibility hook
ReadXML, WriteXML
XmlSchemaProviderAttribute and custom method
for providing the schema
Custom Schema

Design Schema
Can go beyond building complex types from simple types
Define minimum occurrence, maximum occurrence, nillable …
etc
Use Facets to add other constraints
Use attribute XMLSchemaProvider to specify method
that returns the schema
Implement IXMLSerializable
Eventually add schema validation to ReadXML or WriteXML
Proxy Generation

Properties
DataBinding
Shared Types
Same Schema leads to reuse of the same type
Same namespace, name and equivalent schema

Event based Asynchronous model

Proxy Generation Extensibility

SchemaImporterExtensions
New abstract base class that enables
custom code generation when importing a
schema
Extensions inherit from the base class and
implement schema matching and add
custom code
Schema matching options : Namespace,
Element, Shape matching
Event Based Asynchronous
calls
MethodNameAsync to make the call
Handle the MethodNameCompleted Event (callback)
Demo

Event Based Asynchronous Web Service Call

Application Connection
Designer

Designing application interactions

Applications interact through EndPoints
Import an existing WSDL document
Imported as a Web Service EndPoint
Contract Driven Development
Eventually modify some properties
Generate implementation skeleton
Application Connection
Designer

Directly specify most of the contract

Operations
Messages specified through types
Can still design schemas and generate types using VS2005 and
.Net Framework tools
Can use the XMLSchemaProvider to specify schema for the
contract
Web service definition information
Namespace, name
Binding Information
Location, name, namespace
Demo

Application Connection Designer

Summary

Visual Studio 2005 builds on and enhances

current Web Services tools
Better Code driven development
BP conformance
More control over what gets generated and how
Design the service through the Application Connection
Designer
Better Contract Driven development
Interface support
Q&A
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.