ASMX

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
Both approaches end up with Contract

Both Qualify for creating Web Services
Require different skills
May have different interoperability and loose
coupling implications
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.

ASMX

Uploaded by

Copyright:

Available Formats

ASMX

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ASMX

Uploaded by

Copyright:

Available Formats

10 – 12 APRIL 2005 Riyadh, Saudi Arabia

Visual Studio 2005 :

Why do we use Web Services ?

Create Message Interpret Message

All vendors support Web Services but:

Defined by WS-I (Web Services Interoperability

By Default, Web Services generated by VS2005

Building BP conformant Web Services

How do you consume it on a .Net Client ?

Nillable value types through generics

Nillable types support

Both approaches end up with Contract

Code Driven Contract Driven

Code Driven Contract Driven

An interface is a class without implementation

Attributes in the interface

Using Web Service Interfaces

In .Net Framework 1.x, undocumented

Event based Asynchronous model

Event Based Asynchronous Web Service Call

Designing application interactions

Directly specify most of the contract

Application Connection Designer

Visual Studio 2005 builds on and enhances

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.