Ouch! Common XML Web services headaches (and possible

Download Report

Transcript Ouch! Common XML Web services headaches (and possible

WEB390
Ouch! Common XML Web services
headaches (and possible solutions)
Christian Weyer
Microsoft MSDN Regional Director
http://www.xmlwebservices.cc/
What to expect
XML Web services in practice
Not to say: „Real World“ experiences ...
Five common headaches
Best Practices
Lessons Learned
Customers Feedback
Quite a few demos
Web services make me sweat ...
Hm, what
about
message
s?
[WebMethod]
rocks, sucks!?
WS-Trust?
WS-Security?
WS-What?
Prepare your Web services Aspirin®
Including existing XML Schemas & validating
the message
Accessing the raw SOAP message on client
and server side
Dynamically invoking Web services
Using existing types in Web services proxy
classes
Asynchronous programming: Web services
invocation and server-side
WebMethods
Headache #1:
Leverage existing XML Schemas
Several efforts exist for defining industry or
domain specific standard XML Schemas
E.g. SALT, MathML
A lot of companies design data in XSD
So no reinvention of the wheel, please
[WebMethod] just generates XSD based on
the .NET types
Can control generation process through attributes
But no built-in support to import external Schemas
Would be nice to also validate messages
against Schema
Leverage existing XML Schemas
SoapExtensionReflector is your
friend
Use .NET attributes in your service code
Map existing Schemas to your type
classes
Map existing Schemas to your method
parameters
Optionally validate incoming messages
against the underlying XSD
Use a SoapExtension
demo
Using XML Schemas
Headache #2:
Accessing the SOAP message
Web services are actually all about
transfering XML messages
Do not think „Simple Object Access
Protocol“!, better „Service Oriented
Architecture Protocol“
Sometimes we want to see and work with
the SOAP message from the wire
„Look ma: it‘s XML, not objects!“
ASMX does not intrinsically allow us to
view and access the SOAP streams
Accessing the SOAP message
Client side:
Use buckets/slots in proxy class to store
streams and establish a context
Use SoapExtension to inject functionality
in ASMX pipeline
Service side:
Directly access the stream from
HttpContext
Pack this into a SoapExtension
demo
SOAP from the wire
Headache #3:
Dynamically call services
Ready-set-go approach in .NET for
connecting to XML Web services
Create native proxy class from WSDL at
design time
There are situations where you actually
do not know the WSDL yet
At least in testing scenarios
Think grid computing
Need for dynamically binding to and
invoking a service at runtime only
Dynamically call services
Everything needed is in the .NET Framework
CodeDom, Reflection,
ServiceDescriptionImporter,
ICodeCompiler, ...
Build a .NET assembly and use it simply by
calling a few methods on a type
Note: degraded performance! Caching may
help out
Leverage this feature SQL Server 2000 to
invoke Web services at runtime
Use .NET CLR from within a SPROC
Leverage XSP‘s power
demo
Dynamic Web services
invocation
(from SQL Server)
Headache #4:
Type Fidelity?
Yes, Web services are all about XML messages
But we need a programming model to work with
.NET exposes types and classes for ease of
development
Types are modeled in assemblies which should
be used in several layers of application
Use these same types in several Web services,
clients
‚Same‘ regarding XSD (targetNamespace)
Trying to use existing types rather than proxy-built
types
Beware: Web services are not about type
fidelity  .NET Remoting
Type Fidelity?
What counts are the XSD types in WSDL
Have to be in the same namespace to be the same
types
Use [XmlType(Namespace=„My namespace“]
on your type
For VS.NET you have to tweak the generated
classes on the client
Types in different CLR namespaces
Beware of code changes when regenerating
Use wsdl.exe on command line
Visual Studio .NET Add-In for handling issues
would be nice to build
Take a look at the proxy class tool of WSE
Also good for the data binding problem
demo
Using Types
Headache/Recommendation #5:
Asynchronous programming
The truth about today‘s Web services:
They are not yet loosely coupled, asynchronous
We nearly always use HTTP and the Web is slow,
unreliable, bad
You should always think to call Web services
asynchronously
You must do so in a Windows Forms app
Decouple Web service call from GUI thread
Think about one-way calls
There are scenarios where asynchronously
executing WebMethods may also help
Not for simple services, but lenghty background I/O
work
Asynchronous programming
Client side:
Three conceptual approaches: Polling,
WaitHandles, Callbacks
Thoroughly think which approach to use when
Leverages the BeginXXX and EndXXX methods in
proxy class
Attention: WinForms & threads, multiple calls,
faults
Service side:
Async. WebMethods to decouple background
processing
Use carefully, might block threads from thread pool
demo
Asynchronous
programming
Recap – what did we just see?
Best practices from customer projects
[WebMethod] is appropriate for starting
It is not bad – but also not good alone
Good interface and schema design wins!
Debate: what is loosely coupled, what not? Where
is it good, where not?
A lot of headaches can be solved already now
Use built-in, but unknown features
Roll your own extensions
And most important:
This were just five selected headaches – be sure
there are a lot more 
There is more … trust me
To WSDL or not to WSDL
More control over WSDL generation
Legend of passing Binary Data
Never ending story of the Dataset
Unfamous IXmlSerializable mysteries
Where ASMX fails and IHttpHandler comes
to rescue
Databinding against proxy generated types
Interoperability
… and counting ...
- Reminder So you still like
[WebMethod]?
OK, it’s great –
but always remember...
- Reminder “ … love is the
message
and the
message
is love …”
From a song by MSFB
http://www.xmlwebservices.cc/
Resources
Christian‘s Weblog
http://weblogs.asp.net/cweyer/
Expect samples there ...
.NET XML Web services Repertory
http://www.xmlwebservices.cc/
MSDN XML Web services Development Center
http://msdn.microsoft.com/webservices/
MSDN Magazine
http://msdn.microsoft.com/msdnmag/
Yasser Shohoud‘s book
Real World XML Web services
for VB and VB.NET developers
Ask The Experts
Get Your Questions Answered
Meet me!
Wednesday, 11.00 a.m. – 2.00 p.m.
Thursday, 11.00 a.m. – 2.00 p.m.
Well, when sitting here this has just
passed by …
http://www.microsoftregionaldirectors.com/
Community Resources
Community Resources
http://www.microsoft.com/communities/default.mspx
Most Valuable Professional (MVP)
http://www.mvp.support.microsoft.com/
Newsgroups
Converse online with Microsoft Newsgroups, including Worldwide
http://www.microsoft.com/communities/newsgroups/default.mspx
User Groups
Meet and learn with your peers
http://www.microsoft.com/communities/usergroups/default.mspx
evaluations
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.