web390 ouch! common xml web services headaches (and possible solutions) christian weyer microsoft...

28
WEB390 Ouch! Common XML Web services headaches (and possible solutions) Christian Weyer Microsoft MSDN Regional Director http://www.xmlwebservices.cc/

Upload: debra-carson

Post on 02-Jan-2016

214 views

Category:

Documents


0 download

TRANSCRIPT

WEB390Ouch! Common XML Web services headaches (and possible solutions)

Christian WeyerMicrosoft MSDN Regional Directorhttp://www.xmlwebservices.cc/

What to expect

XML Web services in practiceNot to say: „Real World“ experiences ...

Five common headachesBest Practices

Lessons Learned

Customers Feedback

Quite a few demos

Web services make me sweat ...Web services make me sweat ...

Hm, what about

messages?

WS-Trust?WS-Security?

WS-What?

[WebMethod] rocks, sucks!?

Prepare your Web services Aspirin®

Including existing XML Schemas & validating the messageAccessing the raw SOAP message on client and server sideDynamically invoking Web servicesUsing existing types in Web services proxy classesAsynchronous programming: Web services invocation and server-sideWebMethods

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 XSDSo 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 friendUse .NET attributes in your service codeMap existing Schemas to your type classesMap existing Schemas to your method parametersOptionally validate incoming messages against the underlying XSD

Use a SoapExtension

Using XML Schemas

demodemo

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

SOAP from the wire

demodemo

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 FrameworkCodeDom, Reflection, ServiceDescriptionImporter, ICodeCompiler, ...

Build a .NET assembly and use it simply by calling a few methods on a type

Note: degraded performance! Caching mayhelp out

Leverage this feature SQL Server 2000 to invoke Web services at runtime

Use .NET CLR from within a SPROC

Leverage XSP‘s power

Dynamic Web services invocation(from SQL Server)

demodemo

Headache #4:

Type Fidelity?

Yes, Web services are all about XML messagesBut 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 WSDLHave to be in the same namespace to be the same typesUse [XmlType(Namespace=„My namespace“] on your type

For VS.NET you have to tweak the generated classes on the client

Types in different CLR namespacesBeware of code changes when regeneratingUse 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 WSEAlso good for the data binding problem

Using Types

demodemo

Headache/Recommendation #5:

Asynchronous programming

The truth about today‘s Web services:They are not yet loosely coupled, asynchronousWe 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 appDecouple Web service call from GUI threadThink 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

Asynchronous programming

demodemo

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 nowUse built-in, but unknown featuresRoll 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 WSDLMore control over WSDL generationLegend of passing Binary DataNever ending story of the DatasetUnfamous IXmlSerializable mysteriesWhere ASMX fails and IHttpHandler comes to rescueDatabinding against proxy generated typesInteroperability… and counting ...

- Reminder -

So you still like

[WebMethod]?

OK, it’s great –

but always remember...

- Reminder -

“ … love is the

messageand the

message

is love …”From a song by MSFB

http://www.xmlwebservices.cc/

Resources

Christian‘s Webloghttp://weblogs.asp.net/cweyer/Expect samples there ...

.NET XML Web services Repertoryhttp://www.xmlwebservices.cc/

MSDN XML Web services Development Centerhttp://msdn.microsoft.com/webservices/

MSDN Magazinehttp://msdn.microsoft.com/msdnmag/

Yasser Shohoud‘s bookReal World XML Web servicesfor VB and VB.NET developers

Ask The ExpertsGet 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 Resourceshttp://www.microsoft.com/communities/default.mspx

Most Valuable Professional (MVP)http://www.mvp.support.microsoft.com/

NewsgroupsConverse online with Microsoft Newsgroups, including Worldwidehttp://www.microsoft.com/communities/newsgroups/default.mspx

User GroupsMeet and learn with your peershttp://www.microsoft.com/communities/usergroups/default.mspx

evaluationsevaluations

© 2003 Microsoft Corporation. All rights reserved.© 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.