|
>
 Wednesday, July 01, 2009
 |
|
 |
|
|
|
|
|
I have never run into this problem before, but I just realized that in WCF applications when I provide a certificate reference with FindBySubjectName - it can fail if you have two similarly named (not identical) certificates. I don't think this is by design, it has to be a bug, but I found a workaround. Short and Sweet...here it is. If I have a certificate reference like this for "RP": <certificateReference findValue="RP" storeLocation="LocalMachine"
storeName="My" x509FindType="FindBySubjectName"/>
But, I also have a cert named "RPSTS" in the same cert store, the lookup fails because it can't find a unique cert by the name RP. I don't know about you but I think "RP" and "RPSTS" are pretty unique...but not as far as WCF is concerned. I usually use FIndByThumbprint for production code, but for code samples and reference materials I want it to be obvious which cert we are dealing with, it is hard enough to trouble-shoot certs without having to look up thumbprints every time.
A workaround for this is to use FindBySubjectDistinguishedName so this works even if I have "CN=RP" and "CN=RPSTS" in my cert store.
<certificateReference findValue="CN=RP" storeLocation="LocalMachine"
storeName="My" x509FindType="FindBySubjectDistinguishedName"/>
Shweet!
Technorati Tags: WCF, Certificates
|
|
|
 |
|
 |
 Friday, October 31, 2008
 |
|
 |
|
|
|
|
|
"Geneva" is the code name for Microsoft's claims-based access platform (CBA) which comprises three things: - "Geneva" Framework, formerly known as code name "Zermatt"
- "Geneva" Server
- Windows CardSpace "Geneva", formerly known as CardSpace 2
Geneva Framework is a framework for building claim-based applications and services, simplifying how they work with claims at runtime to authorize access; is a framework for building custom security token services; and supplies functionality for issuing managed information cards (for CardSpace and other identity selectors) and functionality for building CardSpace-enabled ASP.NET applications. Geneva Server is the next generation ADFS to support federation not only for web applications (passive federation), but also services (active federation). It is an enterprise worthy security token service that can handle federation and claims transformation. CardSpace Geneva is the next generation of CardSpace. I'll be writing about all of these technologies over the next while, starting with some upcoming articles in MSDN on Geneva Framework.
|
|
|
 |
|
 |
 Friday, April 25, 2008
 |
|
 |
|
|
|
|
|
Here is my usual post-conference post with updated code samples related to the topics I presented on. I did 2 full day tutorials, and 4 sessions...enjoy! Many of the demos come from my book, Learning WCF. Since there is setup required for most of the samples that illustrate security or rely on a database, it is best you download the entire package of samples and follow the setup instructions provided in the appendix. Here's the link: http://www.thatindigogirl.com/LearningWCFCode.aspx TUTORIAL: Improve Your SOA: Designing a Secure, Reliable and Scalable System with WCF TUTORIAL: .NET Roadmap SESSION: ADFS and ASP.NET: Supporting Single Sign-On in your Web Applications SESSION: Building a Router for your Applications SESSION: Going Federated with WCF SESSION: Load Balancing Considerations for WCF - Samples for this instancing and throttling come from my book (see above).
- I have additional samples related to proxies here, including a proxy wrapper to address timeouts and uncaught exceptions that fault the channel: http://www.dasblonde.net/downloads/Proxies.zip
|
|
|
 |
|
 |
 Thursday, April 24, 2008
 |
|
 |
|
|
|
|
|
A few weeks ago I was presenting a code sample that I created last year and discovered a mysterious problem. First, let me explain the sample. It is a proxy wrapper for WCF clients that illustrates how to swallow timeout exceptions and recreate channels automatically when there is an exception that faults the channel. The idea is this: - When a channel with a transport session times out, does the user need to see an error? Not really. But, the exception won't show up until you try to call the service, so my wrapper catches communication exceptions and if they are not faults it creates a new channel and retries the same call to the service once more. The theory is, if it fails again, we probably have a bigger problem. Otherwise, we will have successfully allowed the client to continue working without seeing an error.
- When an uncaught exception from the service faults the channel, the client channel will also be faulted if the call is not one-way. The user should see the error message, even if it is an uncaught exception, but the next time they use the proxy they should get a new channel so they can continue to work. So, the proxy wrapper creates the channel again if the channel is faulted, before making the next call.
I explained this in my ASP.NET Pro article on the subject. The latest code for this is here: http://www.dasblonde.net/downloads/Proxies.zip Well, the problem that In encountered is that all of a sudden my logic for checking if the channel was faulted after a timeout, was failing!!!! It was strange - from one stack frame to another, the channel went from Faulted to Created. But none of my code affected that change! So, of course I thought that something had changed in .NET 3.5 related to channel factory caching that might have had a side-effect of my code...and I didn't have time to investigate further until today while I was talking with my colleague Brian Noyes about the subject. Long story short, he ran the code, reproduced the problem, and remembered that there were some strange behaviors with SUO files for a solution that could cause this. He deleted the SUO and then the sample worked like it originally did!!!!! I did the same, and found the same result. This is really messed up! Apparently this is a common problem, but I have never heard about it before. The real annoyance is the time I spent troubleshooting this before I talked to Brian, and the doubts it put in my mind about new features of WCF and possible regressions....and yet I was wrong...it was the stupid SUO file. What the? Holy? This is an unacceptable bug. Who knows what kind of misleading issues this could cause developers in their day-to-day work. Technorati Tags: WCF, VS 2008
|
|
|
 |
|
 |
 Wednesday, April 09, 2008
 Wednesday, November 14, 2007
 |
|
 |
|
|
|
|
|
Thanks to all that attended the full-day tutorial at Dev Connections last Monday - Improve Your SOA: Designing a Secure, Reliable and Scalable System. It was certainly an avalanche of rich topics related to SOA and WCF. At last I have compiled the long list of resources from the day, including references to some getting started resources for those new to WCF. Getting Started Demos Code from the book is organized by subject matter. I specifically illustrates samples from these subdirectories: \Exceptions, \Security, \Security\ClaimsBased, \Instancing, \Concurrency, \Bindings, \QueuedMessages, \Transactions, \ReliableSessions. If there are other resources you are looking for specifically, please drop me an email and I'll add to this post. Thanks! Technorati Tags: Dev Connections, WCF, SOA
|
|
|
 |
|
 |
 Monday, October 22, 2007
 Saturday, September 15, 2007
 |
|
 |
|
|
|
|
|
As some of you may know, several of us at IDesign (Juval, Brian and myself) are in the midst of a two-week .NET 3.5 Roadshow - six cities in two weeks where we collectively cover WCF, WF, WPF, CardSpace, federated and claims-based security concepts, and some key aspects of .NET 3.5 such as new C# 3.0 language features and ADO.NET 3.5 including LINQ and the Entity Framework. I'm personally covering WCF security, federated and claims-based security, C# 3.0 and ADO.NET 3.5. For those of you attending (or, not) here are links to the code samples I'm presenting: VS 2005 samples Download VS 2008 Samples (UPDATED 10/11/07) This download includes all samples referenced above, in addition to .NET 3.5 samples for C# 3.0 and LINQ, and IDesign's declarative security model including a recent version of our ServiceModelEx library. Other relevant resources discussed: Any questions? Email me. -Michele Technorati Tags: CardSpace, WCF, LINQ, C# 3.0
|
|
|
 |
|
 |
 Wednesday, August 22, 2007
 Thursday, August 16, 2007
 |
|
 |
|
|
|
|
|
Today I completed a webcast as part of a 15 part series - today's subject concurrency, throughput and throttling. I received some questions about callback and Windows client applications that I thought I would elaborate on here. In fact, I went a little overboard and created a bunch of samples that would illustrate the behavior of services and clients when you have a Windows client, a service with a callback contract (thus, two-way communication) and various WCF settings at the client and service that relate to concurrency, multithreading, synchronization with the UI thread, and so on. The following table summarizes various settings at the client, service and callback and the resulting behavior at runtime. Here's the breakdown for each column: - Callback Sync Context - refers to the UseSynchronizationContext setting for the CallbackBehaviorAttribute on the client callback object.
- Callback Concurrency Mode - refers to the ConcurrencyMode setting for the CallbackBehaviorAttribute on the client callback object.
- Service Operation - Indicates if the service contract operations are one-way or two-way.
- Callback Operation - Indicates if the callback contract operations are one-way or two-way.
- Service Concurrency Mode - refers to the ConcurrencyMode setting for the ServiceBehaviorAttribute on the service type.
- Resulting Behavior - when the corresponding sample is run, what happens?
I have also uploaded sample code for each of these scenarios, numbered in order of table row description below. Get the code here. | Callback Sync Context | Callback Concurrency Mode | Service Operation | Callback Operation | Service Concurrency Mode | Resulting Behavior | | True/ False | Single/ Reentrant/ Multiple | One-way/ Two-way | Two-way | Single | These are defaults. InvalidOperationException at the service. Operation would deadlock calling the client application since the callback is two-way and reentrancy isn’t possible. | | True | Single/ Reentrant/ Multiple | Two-way | Two-way | Reentrant/ Multiple | Service able to call client, but client is blocked because of outgoing call. | | False | Single/ Reentrant/ Multiple | Two-way | Two-way | Reentrant/ Multiple | Service able to call client, client callback object is not blocked. If client callback object tries to communicate with UI thread (i.e., setting properties of controls) it will block. | | False | Single | One-way | Two-way | Reentrant/ Multiple | Service able to call client, client callback object is not blocked. Client callback object can communicate with UI thread using Invoke() from callback thread. Client can issue multiple calls to service but only one callback can be processed at a time. | | False | Multiple | One-way | Two-way | Reentrant/ Multiple | Service able to call client, client callback object is not blocked. Client callback object can communicate with UI thread using Invoke() from callback thread. Client can issue multiple calls and multiple callbacks can be processed at a time. | | False | Multiple | One-way | One-way | Single/ Reentrant/ Multiple | Service able to call client, client callback object is not blocked. Client callback object can communicate with UI thread using Invoke() from callback thread. Client can issue multiple calls and multiple callbacks can be processed at a time. | | False | Multiple | Two-way/ Multi-threaded Client | Two-way | Reentrant/ Multiple | Service able to call client, client callback object is not blocked. Client callback object can communicate with UI thread using Invoke() from callback thread. Multiple calls from client can be processed at the service, and multiple callbacks can be processed at the client. | | False | Multiple | Two-way/ Multi-threaded Client | Two-way | Reentrant/ Multiple | Service able to call client, client callback object is not blocked. Client callback can communicate with UI thread using Invoke() from callback thread. Multiple calls from client can be processed at the service, and multiple callbacks can be processed at the client. | Here is a summary of considerations. - Contract design:
- Make callback operations one-way. If this isn’t possible, make the service reentrant. Prefer one-way callbacks since most likely the service doesn’t care about responses.
- If service operations will notify clients with a callback, make them one-way as well.
- Exception handling:
- Remember that uncaught exceptions invalidate service, client and callback channels where sessions are involved. Two-way communication can only happen over duplex, thus there is a transport session (TCP, named pipes) or HTTP session (using reliable sessions over WSDualHttpBinding).
- Throw faults for known exceptions unless you want the client to be forced to recreate the proxy and start a new session. That includes clients – who should not allow exceptions to flow back to the service during a callback unless they intend to destroy the session.
- To avoid destroying the session: if callback operations are one-way, swallow the exception after handling it at the client; if callback operations are two-way, report a fault to the service in response.
- Windows client issues:
- Always disable synchronization with the UI thread for callback objects, by setting UseSynchronizationContext to false in the CallbackBehaviorAttribute.
- Multithreaded clients should invoke services on another thread (can use asynchronous proxies) when callbacks or long running service operations are involved. This prevents UI thread from blocking during call, allows callbacks to communicate freely with UI.
- Use Invoke() to communicate with UI from the callback thread.
- Don’t forget to protect other client state if the callback object supports multiple concurrent callbacks. That means the ConcurrencyMode setting is Multiple in the CallbackBehaviorAttribute.
|
|
|
 |
|
 |
 Monday, April 02, 2007
 |
|
 |
|
|
|
|
|
Once again a fantastic conference in Orlando. Dev Connections just keeps getting better and I always enjoy being part of it. Not to mention the weather in Orlando isn't bad! Here are links to my code samples for each talk I delivered. Enjoy! .NET Technology Roadmap Tutorial ASP.NET and WCF ASP.NET and CardSpace - Demonstrations in this talk can be found here:
WCF Federated Security - My claims-based samples can be found here:
- And, my STS sample here (NOTE: this sample will be updated shortly with an upcoming article, stay tuned!):
WCF Contracts and Versioning ASP.NET Performance (Updated 06/07/2007) Ok people, I had this in my Windows Live Writer to send a long time ago, and somehow it did not post...but since I haven't posted in a while I didn't notice. Many apologies for the delay. Does the "better late than never" statement apply here? I hope so... - In this talk I covered a lot of ground, and theory around performance including simpler performance tips, the progression of asynchronous handlers to component distribution, and the importance of performance counters for your SLAs.
- You can look at my ASP.NET Sandboxing articles and samples for more resources on component distribution.
- See also the following data demos for examples of data caching
- My LocalizedGallery globalization example (posted here) illustrates the use of complex output caching based on custom caching by browser, culture and profile
- Asynchronous HTTP handlers:
- Here is an example showing how to create custom performance counters:
- Here is an example illustrating some of the health monitoring configuration features of ASP.NET 2.0:
|
|
|
 |
|
 |
 Friday, March 23, 2007
 |
|
 |
|
|
|
|
|
I just spent the last week at SD West in San Jose...this year the conference was bigger than ever before! Thanks to everone that attended my tutorials and sessions, I really enjoyed the questions and discussions...as I hope you did. As promised, here is a list of all my resources from the conference talks. Enjoy! Intro to Web Services (Tutorial) - Christian Gross and myself presented this one, discussing everything from POX, REST, RSS, SOAP/WSDL, WS* and SOA.
- Code I demonstrated in this tutorial is from the .NET Web Services tutorial next.
.NET Web Services TODAY (Tutorial) Microsoft Technology Avalanche (Tutorial) Top 10 Web Service Standards You Need To Know WCF Contracts and Versioning - Demonstrations in both of these talks are based on WCF code from my book here: http://www.thatindigogirl.com/LearningWCFCode.aspx
- See \Security, \ReliableSessions, \Transactions in particular for the WS* discussion
- See \DataContracts, \AdvancedSerialization, and \ServiceContracts for the contracts discussion
CardSpace - Demonstrations in this talk can be found here:
The Amazing World of Federated Security - This talk was mostly discussion of standards and architectures however the demonstrations I used to illustrate a few points are based on my claims-based samples here:
- And, my STS sample here (NOTE: this sample will be updated shortly with an upcoming article, stay tuned!):
|
|
|
 |
|
 |
 |
|
 |
|
|
|
|
|
I created a presentation in November of last year with the goal of helping folks make sense of the vast number of Microsoft technologies from development tools, language, data, windows, web and SOA development. This blog post holds the latest links to resources and code for each section. System Requirements The links below use the following technology platforms: - Visual Studio 2005 and .NET 2.0
- .NET 3.0
- NET 3.0 Runtime (installed with Vista)
- Windows SDK for .NET 3.0
- Visual Studio 2005 Orcas Extensions for .NET 3.0:
- WCF&WPF (Nov 2006)
- WF (Nov 2006)
- ADO.NET and LINQ CTP for VS 2005 (May 2006)
- LINQ CTP
- ADO.NET vNext CTP
- ADO.NET vNext Entity Data Model Designer Prototype, CTP
- Visual Studio Orcas CTP (March 2007)
Development Tools In this section I reviewed the stack of development tools and explained how to choose between them. Language Enhancements In this section I talked about moving from .NET 1.1 to 2.0, and discussed the key features of 2.0 that folks should be leveraging. Then, I focused on the language enhancements forthcoming with C# 3.0 and VB 9.0. Demos: Data Access In this section I focused on data access technologies, designing the data access tier, and key features of ADO.NET 2.0, vNext and LINQ to give you some idea how to prepare for the next set of innovations. Demos: - When you install ADO.NET vNext and LINQ there are literally 100s of samples that will really help you get up to speed here. I show a selection of these in this presentation.
Windows Development
In this section I review Windows Forms 2.0 innovations, primarily ClickOnce, and then talk about how to prepare for WPF, explaining the various deployment models. I also talk about practical approaches to choosing the right platform for your development efforts. Demos: Web Development
In this section I showed an ASP.NET sample application that illustrates key features of ASP.NET 2.0 and practical application of those features. Then we looked at AJAX and discussed trends on the Web compared to Windows development. Popular AJAX Frameworks: Demos: Distributed System Programming In this section I reviewed the typical use for earlier distributed computing technologies like remoting, enterprise services and ASMX web services with WSE, and compared them with WCF. BPM and Workflow In this section I discussed BPM, BizTalk and workflow and trends for BizTalk vNext. DinnerNow To pull it all together, there is a sample you can download here: www.dinnernow.com that illustrates all of the technologies in a practical example. It includes WCF, WF, WPF, AJAX, Vista gadgets and mobile apps.
|
|
|
 |
|
 |
 Saturday, March 03, 2007
 |
|
 |
|
|
|
|
|
My sincerest thanks to both groups in Denver and Boulder for having me visit this week to talk about WCF. As promised here are the links to my slides from both talks: WCF Overview WCF Contracts and Versioning As for the code, here is a link to all the code for my Learning WCF book: Learning WCF Code
|
|
|
 |
|
 |
 Sunday, November 12, 2006
 |
|
 |
|
|
|
|
|
A big thanks to all the participated in this monstrous tutorial at Dev Connections. Whew, I can fully admit it was a lot of work to put all the information together in one place, but I hope that you got a lot out of it. For those that didn't attend, the goal of the tutorial was to provide an overview of the current state of the various technologies and tools for Microsoft developers, with an emphasis on the reasons for moving forward with each technology stack, and hopefully some enlightenment on when you might choose each technology. I'll be keeping this one day session current for future conferences, and for on-site sessions with clients. If you are interested in such a thing, contact me at IDesign: www.idesign.net.
Here are the resources I promised from the tutorial.
Development Tools
In this section I reviewed the stack of development tools and explained how to choose between them.
Language Enhancements
In this section I talked about moving from .NET 1.1 to 2.0, and discussed the key features of 2.0 that folks should be leveraging. Then, I focused on the language enhancements forthcoming with C# 3.0 and VB 9.0.
Demos:
Data Access
In this section I focused on data access technologies, designing the data access tier, and key features of ADO.NET 2.0, vNext and LINQ to give you some idea how to prepare for the next set of innovations.
Demos:
- When you install ADO.NET vNext and LINQ there are numerous overview documents, tutorials, and samples that will really help you get up to speed here. These are the demos that I showed in the tutorial.
Windows Development
In this section I reviewed Windows Forms 2.0 innovations, primarily ClickOnce, and then talked about how to prepare for WPF and who should use it today.
Demos:
Web Development
In this section I showed an ASP.NET sample application that illustrates key features of ASP.NET 2.0 and practical application of those features. Then we looked at AJAX and discussed trends on the Web compared to Windows development.
Popular AJAX Frameworks:
Demos:
Distributed System Programming
In this section I reviewed the typical use for earlier distributed computing technologies like remoting, enterprise services and ASMX web services with WSE, and compared them with WCF.
BPM and Workflow
In this section I discussed BPM, BizTalk and workflow.
|
|
|
 |
|
 |
 Thursday, October 12, 2006
 |
|
 |
|
|
|
|
|
For those of you who are attending our .NET 3.0 roadshow (http://www.net3roadshow.com/) here are the updated code samples for my WCF Security and CardSpace talks. As I mentioned in each session, the code has changed since June/July CTP. These samples have been updated for RC1/Sept CTP.
http://www.dasblonde.net/downloads/wcf/CMPSecurityDemos.zip
Also, for those of you who attended the LA show, I forgot to mention that I know of a great job opportunity in Irvine, CA. The company is building a VERY interesting system based on all .NET 3.0 technologies and AJAX. They are hiring now, so if you are looking for this type of opportunity, email me and I'll connect you to explore further. mlb@idesign.net
-Michele
|
|
|
 |
|
 |
 Monday, September 25, 2006
 |
|
 |
|
|
|
|
|
When you own both sides (client and service) it can be more effective for developers to share assemblies for shared types, instead of relying on proxy generation to duplicate types from WSDL. Furthermore, if you want to work with strongly typed collections at the client, and I don't mean BindingList<T>, you may want to specify which collection type.
Here's the SvcUtil command to make this a reality:
svcutil /d:d:\LearningWCF /noconfig /o:serviceproxy.cs /r:ContentTypes.dll /ct:System.Collections.Generic.List`1 http://localhost:8000
One of the reasons that I blogged this seamlingly obvious instruction is because I got caught using a single quote (List'1) instead of a backquote character (List`1) and things were not working quite right. I didn't see it (better glasses?) but Eugene on the WCF team helped me find my way. It's the little things that take up your time!
Cheers!
|
|
|
 |
|
 |
 Thursday, September 21, 2006
 |
|
 |
|
|
|
|
|
I was intrigued by this forum discussion about attaching context to the lifetime of a service operation.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=733385&SiteID=1
Basically, the question is how to create the equivalent of the HttpContext we have with ASP.NET requests. The OperationContext is the closest we have to a request lifecycle, and it turns out you can add to the context by implementing IExtension<OperationContext>.
Attached is a sample: CustomContext.zip (91.4 KB)
Here's how it works:
- I use a custom attribute at the service, that implements IServiceBehavior.
[ApplicationRequestContext] public class HelloIndigoService : IHelloIndigoService
- In IServiceBehavior.ApplyDispatchBehavior() I add a custom message inspector to the MessageInspectors collection for each endpoint. This makes it possible to intercept at the point messages are received, and just before reply messages are sent. In my example, the ApplicationRequestContextAttribue also implements IMessageInspector.
public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) { foreach (ChannelDispatcher channelDispatcher in serviceHostBase.ChannelDispatchers) { foreach (EndpointDispatcher endpointDispatcher in channelDispatcher.Endpoints) { endpointDispatcher.DispatchRuntime.MessageInspectors.Add(this); } } }
- In IMessageInspector.AfterReceiveRequest() I add an instance of my ApplicationRequestContext to the OperationContext, like this:
OperationContext.Current.Extensions.Add(new ApplicationRequestContext());
- In IMessageInspector.BeforeSendReply() I remove the instance of ApplicationRequestContext from the OperationContext. In my opinion, this step should not be necessary, but without it you will not have a chance to clean up what you created in the ApplicationRequestContext to speed up garbage collection.
OperationContext.Current.Extensions.Remove(ApplicationRequestContext.Current);
- The IExtension<OperationContext> implementation has an Attach() and Detach() implementation. In Attach() you intitialize your context. In Detach(), cleanup.
- Anywhere else in the application when you want access to the context, you get it from the OperationContext.Current. I provide a static member in the custom context to get this information:
public static ApplicationRequestContext Current { get {return OperationContext.Current.Extensions.Find<ApplicationRequestContext>();} }
Many thanks to Scott Mason on the WCF team for helping me find the right hooks for this purpose...
|
|
|
 |
|
 |
 Saturday, September 16, 2006
 |
|
 |
|
|
|
|
|
To follow my post on Service Contract Versioning, here's a snip from my book on Data Contract Versioning.
-----
This lab illustrates several versioning scenarios for data contracts. Table 2-5 summarizes possible changes to a data contract and the affect it has on existing clients, if any.
|
Data Contract Changes |
Impact on Existing Clients |
|
Add new non-required members |
Client unaffected. Missing values are initialized to defaults. |
|
Add new required members |
An exception is thrown for missing values. |
|
Remove non-required members |
Data lost at the service. Unable to return the full data set back to the client, for example. No exceptions. |
|
Remove required members |
An exception is thrown when client receives responses from the service with missing values. |
|
Modify existing member data types |
If types are compatible no exception but may receive unexpected results. |
Making changes to data contracts once they have been published is a delicate matter. Even if no exception is thrown for the change, the data may lack integrity once deserialized on either end. To avoid this, a few general guidelines should be followed if you are not creating a new data contract version:
Require data members the business depends on.
Do not remove or change data types for members, ever.
If adding new members, make sure they are not required so that version 1 clients don’t break. Remember that missing fields will be initialized to default values — so you must be sure these defaults are acceptable, or perform some low level message inspection to provide meaningful defaults prior to deserialization.
Support IExtensibleDataObject so that extra data sent by clients, or returned by services, is preserved for round trips.
As the lab illustrates, implementing this interface allows you to preserve unknown members sent in the data contract message element (for example if a version 2 client sends a message to a version 1 service). Predicting future versioning issues is difficult, so providing this property bag for unknown members can ease versioning pain.
If at a later time you decide this is not a desirable feature, you can suppress support for unknown members with the dataContractSerializer behavior:
<behavior name="serviceBehavior">
<dataContractSerializer ignoreExtensionDataObject ="true"/>
</behavior>
If you are wondering about the client side — it so happens that SvcUtil generates data contracts that implement IExtensibleDataObject. This ensures that extra data sent to clients by the service will not be lost in a round trip.
On either side the result is that the DataContractSerializer populates the ExtensionDataObject dictionary on deserialization, and uses the same dictionary to serialize additional elements in outgoing messages.
To properly version a data contract you should create a new type and supply it with a new data contract name and/or namespace using the DataContractAttribute. Since it is a new type, you are free to remove, add, or change any member — but remember that if the semantics of the type are significantly different then it should probably be a new type altogether, without relation to the original.
When you change a data contract that is included in a service contract operation, you are also affecting the service contract that exposes the type. In fact, the minute you decide to version a data contract you must also version any service contract that uses it, or supply new contracts for the new type.
In summary, existing clients must always be able to access an endpoint that exposes the original contract. The only way this is possible is if the original contract does not change!
Versioning Flow Diagrams
Figure 2-7 and Figure 2-8 illustrate the decision flow for data contract versioning based on non-strict and strict approaches, respectively.
With non-strict versioning you can add optional members and ignore (yet preserve) superfluous members that may result from future versions of the contract. Ignoring optional members requires you to be aware of the default initialization of members that are missing, if you want to differentiate from version 1 and version 2 clients. Allowing superfluous members to be ignored solves the problem of newer version clients pushing data to an older version of the data contract, but this carries risks if clients send an inordinate amount of extra data. You should still consider IExtensibleDataObject for your own versioning needs, but perhaps monitor the message size for possible denial-of-service attacks.
With strict data contract versioning all changes lead to a new data contract. That means that any service contract that exposes this new data contract must also be versioned per the rules of strict service contract versioning.
Click image for full view...

|
|
|
 |
|
 |
 |
|
 |
|
|
|
|
|
Oh my, is it really a new post from little 'ole me? Yes, I have been very busy with various projects, including my Learning WCF book which I'm trying to wrap in the next month here...
I am getting a lot of questions about contracts and versioning, and since I have some sections in my book to address this, I thought I'd post them here. Starting with service contracts.
From the book:
-----
This lab illustrates that the service model is by default version tolerant. Table 2-2 summarizes some possible changes to a service contract and the affect it has on existing clients, if any.
|
Service Contract Changes |
Impact on Existing Clients |
|
Adding new parameters to an operation signature |
Client unaffected. New parameters initialized to default values at the service. |
|
Removing parameters from an operation signature |
Client unaffected. Superfluous parameters pass by clients are ignored, data lost at the service. |
|
Modifying parameter types |
An exception will occur if the incoming type from the client cannot be converted to the parameter data type. |
|
Modifying return value types |
An exception will occur if the return value from the service cannot be converted to the expected data type in the client version of the operation signature. |
|
Adding new operations |
Client unaffected. Will not invoke operations it knows nothing about. |
|
Removing operations |
An exception will occur. Messages sent by the client to the service are considered to be using an unknown action header. |
· The bulk of these changes have no direct affect on clients, although the results may be undesirable. The forgiving nature of the service model can be a blessing or a curse depending on how you look at it. Here are some downsides:
You can unwittingly lose information passed by the client
Missing data from the client may not be detected
Type conversions may work, yet the data is semantically invalid
· You can remove the risks of these unexpected results by using data contracts as message parameters and return types. I’ll discuss data contracts in the next section.
· Of course you are entitled to come up with your own strategy for version tolerance, but I recommend that if the implementation semantics of the service contract have changed or if new clients are to be given additional features via extended parameters and/or new operations — you should version the service contract, rather than accepting version tolerance.
To properly version a service contract you should provide a new contract and modify the namespace specified in the ServiceContractAttribute. To version the namespace, you can supply a new value for the year and month, if you follow the naming conventions I’ve recommended. A new contract name should also be specified if the contracts aren’t inherited. In the next two sections I’ll compare two versioning approaches.
· One likely scenario is that you will add new operations without changing the existing service contract. But, you may want to support these new operations at the same endpoint. You can achieve this by creating a new contract that inherits the old contract, adding new operations to the new one. Consider the contract shown in Example 2-8 as the first published version of the service contract.
[ServiceContract(Name="ServiceAContract",
Namespace = "http://www.thatindigogirl.com/samples/2006/06")]
public interface IServiceA
{
[OperationContract]
string Operation1();
[OperationContract]
string Operation2();
}
· The endpoint configuration for the service implementing the contract might look like this:
<endpoint address="ServiceA" contract="BusinessServiceContracts.IServiceA" binding="basicHttpBinding" />
· When new operations are added to the service to extend its features, you may want to expose the same endpoint to old and new clients while still somehow tracking the contract version related to new features. If you extend the original service contract you can add operations under a new namespace as shown in Example 2-9.
[ServiceContract(Name="ServiceAContract",
Namespace = "http://www.thatindigogirl.com/samples/2006/08")]
public interface IServiceA2:IServiceA
{
[OperationContract]
string Operation3();
}
· Note the service contract name is the same, but the namespace has changed. The service type can implement IServiceA2 and it will be able to expose the original operations with their original namespace, while exposing the new operation with the versioned namespace. As such, original clients can hit the same endpoint without impact, while new clients who download the metadata when version 2 is available, can access all operations.
· This scenario does not address the following:
You can’t modify existing operations with contract inheritance
You can’t differentiate old clients from new clients since they hit the same endpoint
· Another approach would be to version the entire contract and create a new endpoint for new clients. In this case, version 2 of the contract might look like that in Example 2-10.
[ServiceContract(Name="ServiceAContract2",
Namespace = "http://www.thatindigogirl.com/samples/2006/08")]
public interface IServiceA2
{
[OperationContract]
string Operation1();
[OperationContract]
string Operation2();
[OperationContract]
string Operation3();
}
· In order to provide a unique WSDL containing only one or the other contract, a unique service type must be created to implement the new contract. Both versions of the service can still share implementation behind the scenes.
· With this implementation the following applies:
You can differentiate old and new clients by service entry point
You can modify existing operations in the new interface (not recommended, you should really provide new operation names)
New clients cannot send messages to the original endpoint
Old clients cannot send messages to the new endpoint
To summarize the discussion of service contract versioning, Figure 2-4 and Figure 2-5 illustrate the decision flow for non-strict and strict-versioning policy, respectively.
Non-strict versioning allows you to add or remove parameters without versioning the service contract. This also means that the implementation code must accommodate how to handle version 1 and version 2 clients. Though possible, the idea of operation signatures changes can be very difficult to track, whereas a data contract as the service operation parameter at least allows for explicitly required and non-required parameters (to be discussed in the "Data Contracts" section of this chapter).
With strict service contract versioning, any change to an operation leads to a new service contract. A new endpoint is always provided to ensure version 2 clients can be differentiated from version 1 clients.
Click the image to see larger view...

|
|
|
 |
|
 |
 Thursday, June 29, 2006
 Wednesday, June 28, 2006
 |
|
 |
|
|
|
|
|
For my web cast today I discussed...well...contracts! In the process I had the opportunity to update my contract chapter samples for my WCF book (the chapters are currently posted to www.thatindigogirl.com for your review, and I'll be updating the posted chapter content for Beta 2 in the next weeks).
The samples are:
Enjoy!
|
|
|
 |
|
 |
 Monday, June 26, 2006
 |
|
 |
|
|
|
|
|
I did a session at Tech Ed on CardSpace (formerly known as InfoCard) that illustrated several ways to integrate CardSpace into your applications. For example you can:
- Use CardSpace to pass claims to a web application using the <object> tag or XHTML (IE 7).
- Use CardSpace to pass claims to a WCF web service using wsHttpBinding/IssuedToken credentials, or wsFederationHttpBinding and specifying a list of claims.
- Use CardSpace to pass claims to a WCF security token service (STS or token issuer) that in turn validates those claims and issues a token for the target WCF service. This involves specifying an alternate token issuer, and implies that that token issuer might trust the CardSpace claims to issue a proper SAML token for the target service.
I have samples for all three, and the delay in posting (sorry) is related to writing up instructions to make sure you are successful...while I was out of town last week.
UPDATED: 06/28/06 to add federation sample
InfoCardBrowser.zip (18.27 KB)
InfoCardWSHttpBinding2.zip (1.98 MB)
MediaServicesFederation.zip (2.07 MB)
Oh, I should also mention that I had lots of help from several product team members to get these samples working on the latest build on short notice - both on the WCF and CardSpace teams...these guys really rock! And you might want to head to Martin Gudgin's blog for more Q&A on the STS he let me use for the federation sample!
Let me know if you have any questions after reading the readme files!
|
|
|
 |
|
 |
|
|
ON THIS PAGE
|
|
|
|
SEARCH
|
|
|
|
CATEGORIES
|
|
|
|
ARCHIVES
|
| | Sun | Mon | Tue | Wed | Thu | Fri | Sat | | 29 | 30 | 31 | 1 | 2 | 3 | 4 | | 5 | 6 | 7 | 8 | 9 | 10 | 11 | | 12 | 13 | 14 | 15 | 16 | 17 | 18 | | 19 | 20 | 21 | 22 | 23 | 24 | 25 | | 26 | 27 | 28 | 29 | 30 | 1 | 2 | | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|
|
BLOGROLL
|
|
|
|
|
 |
|