Hello everybody, it’s been a while since I’ve last posted anything here. As usual, I have multiple reasons – the most important is the lack of time. My company has moved into its first office and it took quite a lot of time to set up everything running smooth, and we’ve a lot of work to do (which is certainly a good thing). Also, I’m currently visiting two universities which take my weekends. But don’t worry, I hadn’t given up my plans on certifications, there will be posts.
As the title says, I have passed the 70-523 exam, which transitions my ASP.NET 3.5 MCPD to Web Developer 4 MCPD. It means a nice WCF cert too (I have passed the exams 70-515 and 70-516, so I don’t receive MCTSs for those).
OK, let’s talk about the exam itself; I know that everyone clicked here is interested on that. So it had four parts for the four respective exams it includes: one for WCF, ASP.NET 4.0, ADO.NET 4.0 and the Web Developer MCPD exam. The time was more than enough, and the questions were moderately hard – but because I passed the ASP.NET and the ADO.NET part before, I knew what to expect on those parts. Read my posts on the 70-561 and 70-562 exams, see what’s new in .NET 4.0 (particularly the Entity Framework) and you are half way on passing this one.
The WCF part was tricky, I have little experience on that subject, but after reading the questions a few times and eliminating the two obviously bad answers, you could catch the logic behind the concept.
The last part was the MCPD exam which I expected to be a little bit harder. There were questions I didn’t know of course, but I could find out the answer for most of them with little more than two years of ASP.NET experience. Of course, you had to go deeper than just ASP.NET – you should know the .NET Framework in general, and a great deal of SQL Server. There were questions about Silverlight, security, application deployment. From the syllabus, I expected some architectural questions, too, but there wasn’t that many (although you better know some architectural patterns, too but they weren’t referenced by their names).
Anyway, this exam wasn’t that bad, but you should have a wider range of knowledge than it was required for its predecessor. I really don’t know what the next one will be – maybe the MCTS on Windows development, but nowadays I did a great deal of Windows 7 client configuration, so it is possible to have a try on 70-680, too. Whichever one I chose, you’ll have your deal of preparation posts for them.
It is clear that in order to be able to call your service, you need to mark the contract interface/class with the ServiceContractAttribute. After this post, it’ll be also clear that you must mark your exposed methods with the OperationContractAttribute. In most cases you’ll be satisfied with the default settings, but there are certain cases (one-way or duplex messaging pattern) when you need to customize the OperationContractAttribute.
Fortunately, it exposes a set of named parameters for implementing such behaviors. Here’s a brief list of them:
|Named Parameters of OperationContractAttribute|
|Action||Controls the action on the request message. The default value is the fully qualified name of the method as an address, for example: http://TheServices/IContract/MyMethod. Set it to an asterisk to indicate an operation which handles all unmatched requests. There’s a constraint on this: there can be only one method like this, and it must take a message as parameter.|
|AsyncPattern||A Boolean value indicating whether the current pattern is asynchronous.|
|IsInitiating||A Boolean value indicating the marked method is the initiation of a session. The default is true.|
|IsOneWay||A Boolean value indicating that the operation returns nothing, and has no output parameters. The default is false. When you set this to true, and return anything else than void, an InvalidOperationException will be thrown at run time.|
|IsTerminating||A Boolean value indicating that after this method the session should be terminated, and the channel closed.|
|Name||Overrides the operation name from the default value: the contract’s method name. This is interesting from the clients point of view. They can call your through the proxy class by the name you specify here (think about IntelliSense support).|
|ProtectionLevel||A member of the System.Net.Security.ProtectionLevel enumeration, indicating the level of protection required by the method.|
|ReplyAction||Controls the action on the reply message. Use it in conjuction|
If you could recall the previous post about Service contracts, I mentioned that you must use serializable types as return/parameter types in your exposed methods. When you build custom types (and you’ll certainly do so) you’ll need to tell WCF either implicitly or explicitly how to serialize your types.
The implicit way is to mark your custom types as serializable, with the SerializableAttribute class. This isn’t too exciting, and doesn’t require you to use data contracts, which are cooler, and will be covered by the exam test. Anyway, you should know that all publicly visible properties and fields will be serialized when you use the implicit method.
The explicit way is to mark your custom types with the DataContractAttribute and the fields/properties with the DataMemberAttribute. Then you’ll gain a finer control over how WCF will serialize and deserialize those types. The DataContractAttribute has the following named parameters:
A service contract is used to define the set of operations a service exposes, its signature, the data types used, the location of the operations and the specific protocols and serialization format of the service.
In WCF, the best practice is to define the service contract as a .NET interface, and implement that interface by your service class. If you expose only some static and not-too-often changing methods in your service, you can omit the interface, and define the contract in the class.
To define the WCF service contract, you’d typically mark your contract interface with the ServiceContractAttribute, but more on this a little bit later.
At the end of the day, XML service contracts will be generated based on your interfaces and contracts, which can be exposed (and understood) by other applications, even those running on different platforms. This is the real power of services, in one word: interoperability.
Now enough of such high level abstraction, let’s dig ourselves into the layer where the actual work is done, and see how to design and implement our service contracts. First the design:
In SOA (Service Oriented Architecture) a service is a self-explaining unit of functionality. Viewed from this aspect, a class or interface is nothing more than a group of related methods and functions, exposed to the client.
Generally, it’s a better idea to use .NET interfaces as service contracts, because:
- Service contract interfaces can extend any number of other contract interfaces
- A class can implement any number of interfaces, thereby any number of contracts
- You can easily modify the service implementation in the class, while the service contracts encapsulated in an interface remains the same
- Versioning is enabled by implementing the old interface in a new one