|
|
Browse by Tags
All Tags » .NET 3.0 - WCF (RSS)
-
One of our core products, Gama System eArchive was accredited last week. This is the first accreditation of a domestic product and the first one covering long term electronic document storage in a SOA based system. Every document stored inside the Gama System eArchive product is now legally legal. No questions asked. Accreditation is done by a national body and represents the last step in a formal acknowledgement to holiness. That means a lot to me, even more to our company . The following blog entries were (in)directly inspired by the development of this product: Laws and Digital Signatures Reliable Messaging and Retry Timeouts Approaches to Document Style Parameter Models XmlSerializer, Ambient XML Namespaces and Digital Signatures Security Sessions and Service Throttling Reliable Message Delivery Reliable Message Delivery Continued Durable Reliable Messaging We've made a lot of effort to get this thing developed and accredited. This , this , this , this , this , this , this , this and t h o s e are direct approvals of our correct decisions. Read More...
|
-
Just came back from today's talk on WCF session support. Deliverables: PPT Code Remember: proxy.Close() is your friend . Read More...
|
-
WCF includes support for establishing a security session through a simple configuration attribute. The primary reason of a security session is a shared security context which enables clients and services to use a faster, symmetric cryptographic exchange. WCF sessions should not be thought of in terms of HTTP based sessions, since the former are initiated by clients and the latter by the servers. In other terms, WCF sessions are there to support some kind of shared context between a particular client and a service. This context can be anything, and is not limited to security contexts. The attribute that establishes a security session and shared context is called, well, establishSecurityContext and is present in binding configuration. An example of such a binding would be: <bindings> <wsHttpBinding> <binding name="SecureBinding"> <security mode ="Message"> <message clientCredentialType="Certificate" establishSecurityContext="true"/> </security> </binding> </wsHttpBinding> <bindings> This binding allows HTTP based communication, demands message based security (think WS-Security) and uses certificates to sign/encrypt the message content. The attribute establishSecurityContext is set to true , which actually enforces a WS-SecureConversation session between the client and the service. The following is a simplified version of what is going on under the covers: Client instantiates the service proxy No message exchange is taking place yet. Client requests a SCT (Secure Context Token) This is done by the infrastructure, when the first service method is called. SCT (again simplified) represents a secure context, which includes the symmetric key. The message which demands it is (per WS-SecureConversation spec) called RST (Request Secure Token). Service responds with RSTR (Request Secure Token Response) message Session bootstraps and is ready to piggyback all further message exchanges. What is not well known is that there is a Read More...
|
-
I'm thinking about reliable messaging these days (isn't it evident ?). There are a couple of specific reasons for that. First, I can imagine a wonderful world of seamless message delivery. Second, currently there are technology limitations that prohibit what most of the industry would like to see. Let's take a look. There's a sentence in the first post of the series that says: There is no durable reliable messaging support in WCF. This is conditionally true. There are built-in bindings that support MSMQ integration and use MSMQ transport as a delivery mechanism, thus making the message exchange durable. Limitations of this approach include platform dependence , durable store dependence and more importantly, one-way messaging . To implement a durable duplex session one would need to implement two one-way service contracts. Downside? Forget about clients sitting behing a NAT without poking holes in your firewalls. There are multiple uses for having durable messaging, the most prominent being different client/service lifetimes. Why can't I dispatch a message to a service when the service is down or I have no network connectivity? Reliable messaging support in WCF is designed to support reliable transport and does not make any assurances of what happens to messages when they hit both ends of the wire . The problem is not in the WCF implementation but rather the WS-RM spec, which does not imply on how and when a message should/must be persisted. There are different implementations of durable transports or at least, some people are already thinking about it. Amazon's SQS Transport for WCF is a good idea, and so is SQL Server SSB usage... if you control both ends of the wire. The industry (read WS-* stack) needs a specification which will cover interoperable + durable message delivery . BYODS ("bring your own durable store") concept would be efficient only when demanding a durable store on the other side of the wire, is governed by a messaging specification. Read More...
|
-
Everything about WCF is about keeping your service boundary intact . By default this also applies to exposing/publishing metadata . In ASMX days, one would need to opt-out of exposing metadata, while in WCF, one has to opt-in . Let's say, for example, you have the following service config declaration: <?xml version="1.0" encoding="utf-8" ?> <configuration> <system.serviceModel> <services> <service name = "Exposing.Metadata"> <host> <baseAddresses> <add baseAddress = "http://localhost:123/MetadataService "> </baseAddresses> </host> <endpoint address = "" binding = "wsHttpBinding" contract = "Exposing.IServiceContract"/> </service> </services> </system.serviceModel> </configuration> This would host Exposing.Metadata service and define a single wsHttpBinding based endpoint listening at the base address. So, the service endpoint address is http://localhost:123/MetadataService . If you would hit the endpoint URL with a web browser, a nice service page would be returned telling you that you have created a service, but there is no metadata exposed . So, hitting the endpoint with svcutil.exe would not allow you to grab metadata and generate the proxy code. WCF, by default, does not expose any metadata . You have to ask for it nicely . There are a couple of options to expose metadata of WCF services. The most basic way of doing it would be to expose it via HTTP based Get requests and retrieve WSDL. The following code fragment would do it, if you hosted the service using a ServiceHost class: [ 1] using (ServiceHost sh = new ServiceHost(typeof(OpService))) [ 2] { [ 3] ServiceMetadataBehavior smb = new ServiceMetadataBehavior(); [ 4] smb.HttpGetEnabled = true; [ 5] sh.Description.Behaviors.Add(smb); [ 6] sh.Open(); [ 7] Console.WriteLine("Service running..."); [ 8] [ 9] Console.ReadLine(); [10] sh.Close(); [11] } Lines 3-5 instantiate and add a service behavior that allows a simple HTTP Get Read More...
|
-
In the previous post we discussed possible scenarios and methods for configuring reliable message delivery in WCF. Let's look further into this great WCF feature. Delivery assurances can have a large impact on the way your code processes incoming messages. Especially, ordering can be of importance if your code relies on ordered message delivery. Since configuration can be changed by any WCF service administrator there is a knob in WCF which lets you demand the appropriate binding . The knob is in a form of a declarative attribute, called DeliveryRequirementsAttribute . Here's how it's used: [DeliveryRequirements(RequireOrderedDelivery = true, QueuedDeliveryRequirements = QueuedDeliveryRequirementsMode.Required)] interface IServiceContract { int Operation(int a, int b); } DeliveryRequirementsAttribute can be set on any service interface or service class implementation. It has three properties: QueuedDeliveryRequirements which has three possible values, Allowed , NotAllowed and Required . Setting NotAllowed or Required makes the binding either demand or prevent WS-RM usage. Setting Allowed does not make any requirements. RequireOrderedDelivery demands a binding that supports and has ordered delivery turned on . TargetContract property is applicable only when the attibute is applied to a class definition. Since WCF service interfaces can be implemented by multiple classes, one can specify a specific interface for which the queued delivery requirements are defined. The specified contract interface would demand a WS-RM capable binding and thus prevent service administrators to turn reliable delivery off. In case where an administrator would turn reliable delivery (or ordering, in this case) off, the service host would throw an exception while trying to host the service. So, DeliveryRequirementsAttribute guards developers from wrongdoings of service administrators. It should set QueuedDeliveryRequirements = QueuedDeliveryRequirementsMode.Required or RequireOrderedDelivery Read More...
|
-
Windows Communication Foundation includes concepts which enable the developer to insist on reliably delivering messages in both directions. The mechanism is actually transport agnostic and allows messages to be flown reliably from client to service and replies from service to client. Underneath, WS-ReliableMessaging (WS-RM) implementation is used. Click here for Microsoft's specification. Content is the same. WS-RM is based on a concept of a message sequence. You can think of it in terms of a session, although it does not carry HTTP session semantics (remember, it's transport agnostic). A communication initiator (RM source) sends a <CreateSequence> element inside the message body to establish a RM sequence. Service side (RM destination) responds with either <CreateSequenceReponse> or <CreateSequenceRefused> , in cases where new sequence is not welcome. After the sequence is initialized there is an additional SOAP Header in messages that identify the message number being transferred. The following is a simple example of headers of the first two messages: <S:Envelope> <S:Header> ... <wsrm:Sequence> <wsrm:Identifier>http://webservices.gama-system.com/RM/Service</wsrm:Identifier> <wsrm:MessageNumber>1</wsrm:MessageNumber> </wsrm:Sequence> </S:Header> ... <S:Body> ... </S:Body> </S:Envelope> <S:Envelope> <S:Header> ... <wsrm:Sequence> <wsrm:Identifier>http://webservices.gama-system.com/RM/Service</wsrm:Identifier> <wsrm:MessageNumber>2</wsrm:MessageNumber> </wsrm:Sequence> </S:Header> ... <S:Body> ... </S:Body> </S:Envelope> After all messages have been exchanged and acknowledged, the RM destination sends a <SequenceAcknowledgement> inside the body of the message. RM source (communication initiator) then tears down the sequence with a <TerminateSequence> message. So, how can this specification be implemented Read More...
|
-
This must be one of the best Channel 9 interviews of all time. Rory did make quite an effort to handle the guys, but at building 42 , what can you expect. It all seems as the Brady Bunch of Microsoft on tape, but they sure did ship the most important Microsoft technology stack of the decade. Well done on both parts. Read More...
|
-
This must be one of the best Channel 9 interviews of all time. Rory did make quite an effort to handle the guys, but at building 42 , what can you expect. It all seems as the Brady Bunch of Microsoft on tape, but they sure did ship the most important Microsoft technology stack of the decade. Well done on both parts. Read More...
|
|
|
|