Tags: wcf |
Posted by
blockwood on
1/21/2010 5:44 AM |
Comments (0)
Here is a great post found on codeproject.com http://www.codeproject.com/KB/WCF/WCFFAQPart3.aspx
Below are some worth looking into:
Note :- The below table is taken from book Pro WCF: Practical Microsoft SOA Implementation -- Chris peiris and Denis mulder – Apress 2007
Below is a table which shows for which binding which mode is supported. We did not discuss the mixed mode. It’s nothing but combination of transport and mixed mode. For instance data encrypted and passed over WsHttp using HTTPS is a mixed mode of security. Encryption is nothing but message security and HTTPS is a transport mode. In a combination they form mixed mode.
|
Binding
|
Transport Mode?
|
Message Mode?
|
Mixed Mode?
|
|
BasicHttpBinding
|
Yes
|
Yes
|
Yes
|
|
WsHttpBinding
|
Yes
|
Yes
|
Yes
|
|
WsDualHttpBinding
|
No
|
Yes
|
No
|
|
NetTcpBinding
|
Yes
|
Yes
|
Yes
|
|
NetNamedPipeBinding
|
Yes
|
No
|
No
|
|
NetMsmqBinding
|
Yes
|
Yes
|
No
|
|
MsmqIntegrationBinding
|
Yes
|
No
|
No
|
So what are the scenarios, advantages and disadvantages of transport VS message security?
|
|
Transport
|
Message
|
|
Scenarios when we should be using one of them
|
When there are no intermediate systems in between this is the best methodology.
If it’s an intranet type of solution this is most recommended methodology.
|
When there are intermediate systems like one more WCF service through which message is routed then message security is the way to go.
|
|
Advantages
|
- Does not need any extra coding as protocol inherent security is used.
- Performance is better as we can use hardware accelerators to enhance performance.
- There is lot of interoperability support and communicating clients do not need to understand WS security as it’s built in the protocol itself.
|
- Provides end to end security as it’s not dependent on protocol. Any intermediate hop in network does not affect the application.
- Supports wide set of security options as it is not dependent on protocol. We can also implement custom security.
|
|
Disadvantages
|
- As it’s a protocol implemented security so it works only point to point.
- As security is dependent on protocol it has limited security support and is bounded to the protocol security limitations.
|
- Needs application refactoring to implement security.
- As every message is encrypted and signed there are performance issues.
- Does not support interoperability with old ASMX webservices/
|
The following table is referenced from the 6461 Microsoft Official Courseware:
Not all bindings provide all security modes. The main reason that a binding may not provide all security modes is because the binding does not support some fundamental characteristic that the security mode requires. The following table lists which bindings support which modes.
|
Binding
|
Transport Security
|
Message Security
|
|
BasicHttp
|
HTTPS
|
WS-Security
|
| WSHttp |
HTTPS |
WS-Security
|
|
WSDualHttp
|
Not supported
|
WS-Security
|
|
NetTcp
|
Transport Layer Security (TLS)
|
WS-Security
|
|
NetNamedPipe
|
Transport Layer Security (TLS)
|
Not supported
|
|
MsmqIntegration
|
MSMQ Transport Security
|
Not supported
|
|
NetMsmq
|
MSMQ Transport Security
|
WS-Security
|
|
WSFederationHttp
|
HTTPS
|
WS-Security
|
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5
Tags: wcf |
Posted by
blockwood on
1/20/2010 12:35 AM |
Comments (0)
Richard Blewett is one of the moderators of the
MSDN WCF Forum. One of the main areas of questions on the forum is duplex messaging – particularly using the WSDualHttpBinding. So instead of typing long messages repeating the same thing in answer to these questions he decided to write this blog post to give a bit of background about duplex messaging and then discuss the options for bindings and common problems people have. His post and related posts can be found here:
http://www.dotnetconsult.co.uk/weblog2/
What is Duplex Messaging?
There are many ways that messages can be exchanged between two parties in a service based system: the client can send messages to the server and never get any back; the client can send a message and wait for a response; the client and service can send eachother messages without any pre-defined pattern; the client can send the service a message but not wait synchronously for a response and then then service can send a message back asynchronously; and there are many others. However, the first three of these are supported natively in WCF and are known as One-way, request/response and duplex.
So Duplex messaging is where, unsolicited, the client and service can send eachother messages. Most commonly this is characterized by the service sending the client “events” or notifications or progress of “interesting things”.
Duplex Contracts in WCF
To send messages to eachother the client and service must have an idea of what operations are available and what messages are sent and received during the communication. In WCF this idea is modelled by the contract. Now normally a contract just determines what functionality is available at the service. However, now the service is going to be sending messages to the client that the client isn’t specifically waiting for so it needs an idea of what messages the client can deal with. So we need a contract that models both directions of the conversation.
A bi-directional contract is modelled using two interfaces bound together with a ServiceContract – like this:
[ServiceContract(CallbackContract=typeof(IPizzaProgress))]
interface IOrderPizza
{
[OperationContract]
void PlaceOrder(string PizzaType);
}
interface IPizzaProgress
{
[OperationContract]
void TimeRemaining(int minutes);
[OperationContract]
void PizzaReady();
}
The import bit here is the CallbackContract that establishes the relationship between the service’s and client’s contracts.
Writing the Service
The service is implemented normally apart from two issues: firstly it needs to access the callback contract to be able to send messages back to the client; secondly the communication infrastructure (modelled by the binding) needs to be able to cope with duplex messaging. Firstly lets look at accessing the callback contract:
class PingService : IOrderPizza
{
IPizzaProgress callback;
public void PlaceOrder(string PizzaType)
{
callback = OperationContext.Current.GetCallbackChannel();
Action preparePizza = PreparePizza;
preparePizza.BeginInvoke(ar => preparePizza.EndInvoke(ar), null);
}
void PreparePizza()
{
for (int i = 10 - 1; i >= 0; i--)
{
callback.TimeRemaining(i);
Thread.Sleep(1000);
}
callback.PizzaReady();
}
}
The critical line here is calling GetCallbackContract on the OperationContext. This gives the service access to a proxy to call back to the client.
Now the service also needs to use a contract that is compatible with duplex messaging. WSHttpBinding is the default for the built in WCF projects but it does not support duplex messaging. People generally then move to the WSDualHttpBinding which is similar to the WSHttpBinding but does support duplex. I will go into more depth about bindings for duplex shortly but for now lets stick to this for now - it will work in our test rig on a single machine without issue.
Writing the Client
If the client is going to receive these messages it needs to provide an implementation of the callback contract. It can gets its definition from either a shared contract assembly or from metadata. If using metadata the callback contract will be named the same as the service’s contract but with the work Callback appended. It will also need to supply this implementation to the WCF infrastructure and it does this by wrapping an instance in an InstanceContext object and passing it to the proxy constructor. So here is the client:
class Program
{
static void Main(string[] args)
{
InstanceContext ctx = new InstanceContext(new Callback());
OrderPizzaClient proxy = new OrderPizzaClient(ctx);
proxy.PlaceOrder("Pepperoni");
Console.WriteLine("press enter to exit");
Console.ReadLine();
}
}
class Callback : IOrderPizzaCallback
{
public void TimeRemaining(int minutes)
{
Console.WriteLine("{0} seconds remaining", minutes);
}
public void PizzaReady()
{
Console.WriteLine("Pizza is ready");
}
}
Running the service and the client will have this working quite happily – so it would seem that duplex messaging and WCF works very well … so why on earth do people keep asking questions about it on the WCF forums?
It Worked on My Machine but Broke when we Deployed It!
Ahh well you probably did the thing that is obvious but almost always a bad idea. You went and chose WSDualHttpBinding as your duplex binding. To understand why this is a bad idea we need to dig a little deeper into how the WSDualHttpBinding works. HTTP is a unidirectional protocol: the client makes a request and the server sends a response. There is no way for a server to initiate an exchange with the client. So how on earth is duplex messaging going to work because it requires exactly this facility? Well the “Dual” in the name is significant, the WSDualHttpBinding actually consists of two connections: one outbound from client to server and one inbound from server to client – this second connection may already be ringing alarm bells with you. The are a two big problems with inbound connections to a client: firewalls very often block inbound connections to clients; the client may not be reachable from the server, it may be using NAT translation behind a router and so cannot be contacted without port forwarding being set up on the router. Both of these issues are showstoppers in real network topologies. You can take some small steps to help – you can specify what port the client should listen on for example by using the clientBaseAddress property of the WSDualHttpBinding. This means the network admin will only have to punch one hole in their firewall (but lets face it, network admins don’t allow any holes to be punched in the firewall).
So if you really shouldn’t use WSDualHttpBinding for duplex, what should you use instead? Well NetTcpBinding supports duplex out of the box and the nice thing about this is that the outbound connection that it establishes can also be used be used for inbound traffic – suddenly we don;t have the inbound connection firewall/NAT issues. “But hold on, isn’t NetTcpBinding for intranet? I’ve read books that tell me that in their ‘which binding should I use?’ flowcharts!” Well it turns out those flowcharts are talking rubbish – NetTcpBinding works very happily over the internet, its just not interoperable by design. “Aha! but I need interop so WSDualHttpBinding is for me!” Well unfortunately not, NetTcpBinding is non-interoperable by design, WSDualHttpBinding is non-interoperable despite its design. From the name it would suggest interoperability but Arun Gupta from Sun wrote this excellent post describing why it wasn’t.
So now seeing that we really are not talking about interop anyway, NetTcpBinding is far more useful than WSDualHttpBinding. Its not bullet proof, if the firewall only allows outbound port 80 but also allows inbound port 80, then WSDualHttpBinding would work where NetTcpBinding wouldn’t – but in this situation we’re really talking server to server and so I’d argue its probably better to roll your own bidirectional communication with two standard HTTP based connections.
The final option you have for duplex communication is to add a piece of infrastructure into the mix. The .NET Services Service Bus (part of the Azure platform) allows two parties to exchange messages both making outbound connections – potentially even using HTTP port 80. The two outbound connections rendezvous in the Service Bus which mediates their message exchanges. If the receiver has had to use outbound port 80 then it polls to receive message bound for it.
It Worked for the First 10 Clients and then the Rest Timed Out!
Irrespective if which of the standard bindings you are using, duplex assumes a constant relationship between proxy and service. In WCF this idea is modelled by the concept of session. All duplex bindings require session. A while back I wrote in some detail about sessions. You will have to either put up with increasing the session throttle (see the linked article for details) or roll your own custom binding that can do duplex without session – you can find an example of this here.
I Use the Callback While the Client is calling the Service and it Deadlocks!
This is because your client is probably a Rich Client GUI based application (Windows Forms or WPF). To understand why this is a problem we need to step back briefly and look at UI clients, threading and WCF threading. UI applications have a rule: you must only update the UI from the thread that created those UI components. In general a GUI application has one UI thread so anything that changes the UI needs to be done from that thread. .NET 2.0 introduced a new construct to simplify the process of a background thread updating the UI: SynchronizationContext. The idea is that a UI framework creates an implementation of a SynchronizationContext derived class that handles the mechanics of marshalling a call on to the UI thread. An instance of this implementation is then made available on the UI and accessible via the SynchronizationContext.Current.
WCF adds more complexity into the mix by enforcing a rule that says “unless you tell me otherwise I will only allow one thread at a time into an object that I control”. You see this with singleton services that will only allow one call at a time by default. The same is also true of the callback implementation object – so WCF will only allow one active thread in the client at a time. So while WCF is performing an outbound call it will not allow an inbound call into the object. This causes the initial problem with the deadlock that the service’s callback cannot be dispatched while the client’s outbound call is in progress. To solve this we use the “unless you tell me otherwise” part of the above rule. You do this by annotating the callback implementation class with a [CallbackBehavior] attribute like this:
[CallbackBehavior(ConcurrencyMode=ConcurrencyMode.Reentrant)]
class Callback : IOrderPizzaCallback
{
public void TimeRemaining(int minutes)
{
Console.WriteLine("{0} seconds remaining", minutes);
}
public void PizzaReady()
{
Console.WriteLine("Pizza is ready");
}
}
But now there is another problem: by default WCF will attempt to dispatch using an available SynchronizationContext. The problem with this callback is the UI thread is already blocked in an outbound call. SO for the call to dispatch we need to tell WCF not to use the SynchronizationContext – again using the CallbackBehavior attribute:
[CallbackBehavior(ConcurrencyMode=ConcurrencyMode.Reentrant, UseSynchronizationContext=false)]
class Callback : IOrderPizzaCallback
{
...
}
Now the issue is of course that the call is going to be processed on a non UI thread so you would have to manually marshal any UI interaction using the SynchronizationContext.Post method.
Duplex messaging can be a useful message exchange pattern but in WCF there can be some unexpected issues. Hopefully this blog post clarifies those issues and demonstrates workarounds for them.
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5
One of the most highly anticipated of the new technologies coming in .NET 4.0 and Silverlight 4.0 is the Managed Extensibility Framework (MEF). Folks that are familiar with Prism and that have been looking at MEF have been wondering how Prism and MEF relate to each other. At a high level, MEF shares some of the same goals as Prism in terms of supporting easy to extend applications, and this has led to a lot of questions on how MEF and Prism relate to each other and about the future direction of Prism once MEF is released next year. Hopefully this post will go a long to clearing up the confusion and give you a sense of how we think Prism and MEF will work together.
First of all, it’s important to note that Prism and MEF are very much complementary technologies. MEF allows you to create extensible applications by providing support for automatic component discovery and composition. It does not focus on application- or UI-level patterns or on any specific UI technology. Prism on the other hand provides support for creating modular composite client applications built on Silverlight and/or WPF. As such it supports a wide range of patterns including the higher level UI patterns and concepts that are need to support composite clients – such as modularity, module deployment, loosely coupled communication, commanding, and separated presentation patterns such as Model-View-ViewModel, etc.
There is clearly some overlap between MEF and Prism (since modular composite client applications are by definition extensible!!) but MEF by itself in no way replaces or obviates the need for Prism – they are each targeted at different parts of the overall puzzle. MEF in fact is fantastic news for Prism, because it means that we can now leverage core capabilities that are provided by the .NET Framework, whereas in the past we’ve had to build those capabilities as part of Prism itself.
Prism 4.0
In the next version of Prism (Prism 4.0) we’ll be focusing on leveraging MEF as much as possible and ensuring that Prism and MEF work seamlessly together. We’ll be kicking off the Prism 4.0 project early next year and, as always, we’ll be providing drops every two weeks during development so you’ll be able to provide feedback and direct the scope and focus of the project as we go. But since MEF integration is likely be one of the first things that we’ll tackle, I think it’s worth describing our current thinking on how we think Prism can leverage MEF and how they can complement each other so that you can provide feedback to us before we start. In the rest of this post I’ll outline a couple of the areas where I think MEF and Prism can be closely integrated. Let me know what you think.
Component Composition
Firstly, let’s talk about component composition. Prism uses the Dependency Injection pattern (DI) quite extensively because it helps to maintain loose coupling between the various components in an application. I’m not going to get into the “is MEF a DI container or isn’t it” discussion here :-) but suffice it to say that there are similarities and differences between the way MEF works and the way that typical Dependency Injection containers work. The upshot is that there are things that MEF does well and there are things that DI containers do well, but the important thing is that both MEF and DI containers promote loose coupling between components, which is a very good thing.
In the Prism 2.0 Quick Starts and the Reference Implementation we use the Unity Application Block as our DI container of choice. However, it’s important to note that the Prism code libraries themselves do NOT depend explicitly on Unity, or in fact on any specific DI container implementation. This is an important point. It was an explicit design decision to allow the use of any other DI container (such as CastleWindsor, StructureMap, AutoFac, Ninject, etc) or the use of any other kind of component composition strategy that suites your needs – such as the component composition strategy supported by MEF!
So the design of Prism allows you to use MEF with Prism 2.0 today, even though Prism 2.0 was shipped early this year way before MEF was broadly available. It’s pretty easy to use MEF instead of a DI container within a Prism module to help you wire up Views, ViewModels, Controllers, or Presenters, or to get references to EventAggregator or RegionManager instances provided by the Shell. In fact, using MEF like this can actually simplify the code somewhat since it can automatically discover available types without you having to register them explicitly with the DI container. You can also use MEF’s meta-data support to do conditional component composition. We’ll be exploring and providing guidance for these scenarios in Prism 4.0.
Another interesting possibility is to use both MEF and a DI container together in the same application. There are some advantages to this since it allows you to leverage the strengths of each in various situations. In fact, Unity 2.0 (which is currently in development as part of EntLib 5.0) will support the hybrid use of MEF and a DI container and make it seamless and straightforward. In Prism 4.0, we’ll be exploring and providing guidance for the use of MEF + DI container hybrid approaches in the context of composite client application development.
Catalogs and Modules
The use of MEF and/or DI container to help with component composition is pretty straightforward, and largely independent of the higher level constructs and patterns in Prism. But one area where the overlap between MEF and these higher level Prism concepts is not quite as clear cut is in the area of Catalogs and Modules. This area has caused some confusion in part because of overlapping terminology and, in some cases, because of the similar concepts applied at different levels of granularity.
To recap, Prism uses the notion of a module to represent a collection of features, components, and resources that make up a functional unit within the application. Prism modules can be developed, tested and deployed independently. They frequently consist of multiple assemblies and other resources packaged up into an easily deployable unit (for example in a XAP file). Prism provides infrastructure for the flexible deployment of modules. In the case of Silverlight, for example, modules can be downloaded with the core application, or can be downloaded in the background or on-demand.
Prism applications use a module catalog to tell it which modules to load. Module catalogs can be static (i.e. the list of modules is predetermined before run-time) or dynamic (i.e. the list of modules is determined at run-time and can take into account the user’s ID, role, configuration, installed modules, wind direction, etc). Dynamic module catalogs can be used to extend an application after its initial deployment. They can be implemented in many different ways. For example, you can build a dynamic catalog by reading a (local or remote) config file, or by using a web service that specifies the modules to load, or by scanning a particular folder to see what modules have been installed.
Once a module is loaded, Prism looks for an entry type that supports the IModule interface. This interface has only one method – Initialize – and can be used to provide any initialization logic that the module provides. Typically, this method is used to register types within the module with the DI container so that they can be accessed by other modules and the shell. Another common use of this method is to register Views contained within the module with UI regions. The module can do anything it needs to though, including kicking off background threads, making web service calls or downloading additional data or resources. Of course, you don’t have to provide any initialization logic if your module doesn’t require it.
Now, MEF too has the concept of a component catalog. When you import a type in MEF (i.e. you’ve expressed a dependency in one class to another class of a certain type), its resolves that type by looking in the MEF catalog which defines all of the types that are available for export (i.e. types that can be used by MEF to satisfy imports). This is a very powerful feature of MEF and allows you to express dependencies between components and have them fulfilled for you pretty much automatically, without having to explicitly register types with a DI container or having to resort to closely-coupled techniques like ‘new’ or CreateInstance. Note, I say ‘type’ here to keep things simple but MEF generalizes the relationship between importer and exporter using contracts, but contracts most often equate to types, and types can be interfaces.
So Prism module catalogs are really not the same as MEF catalogs since they’re specifying things at completely different levels of granularity. In addition, MEF does not provide any support for the packaging or conditional deployment of functional units within an application. However, there is clearly some overlap here since, at a lower level, Prism modules essentially contain a bunch of components that can import and export types so that they can be hooked up to components from other modules or the shell.
You can imagine using both Prism module catalogs and MEF catalogs together. The key here I think is for Prism to focus on the packaging, deployment and activation of coarse grained functional units (modules), as defined by either a static or dynamic module catalog, and to use MEF to support the flexible, meta-data driven composition of components within and across modules and the shell.
For example, imagine using Prism to build modules that represent functional units within an application and having it take care of their packaging and deployment via a dynamic or static module catalog. As each Prism module is loaded, the component dependencies within it (i.e. imports and exports) can be made available to MEF for component composition. In a sense, each module represents a catalog of components that MEF can use to fulfill and resolve component dependencies. There are other possibilities I am sure, and we’ll be exploring these as part of Prism 4.0…
Prism 4.0 Needs You!
Our goal for Prism 4.0 is to leverage MEF, and other .NET 4.0 and Silverlight 4.0 features, as much as possible so that we can provide a flexible and powerful environment for building modular, composite client applications on WPF and Silverlight 4.0. MEF is an exciting new technology and it’s great to see some level of support for loosely coupled component composition finally make it into the .NET Framework. I’m looking forward to exploring the possibilities here and I think it’s going to be pretty cool…
As well as MEF integration, for Prism 4.0 we’re looking at also providing more guidance on the ViewModel pattern, navigation, out of browser applications, developer/designer workflow, user experience patterns, visual studio templates, and a whole host of other areas. Which ones we tackle will depend on you, so as always, if you have any ideas or feedback, please let us know!
This post was originated by David Hill. The original post, comments and further discussion can be found here: http://blogs.msdn.com/dphill/archive/2009/12/09/prism-and-mef.aspx
Currently rated 5.0 by 1 people
- Currently 5/5 Stars.
- 1
- 2
- 3
- 4
- 5
Today my cousin and I were talking and he mentioned how he read that Windows 7 can go into a god mode and all it takes is creating a folder with a particular name. So of course to have that kind of power would be pretty awesome. As I sit here thinking about this post (and yes I'll let you know how to do it soon) I feel like saying out loud "with power like this don't let it get into the wrong hands" as an image of superhero comics flash before my mind.
God mode allows you to access everything on your system from one place. Just to verify that this works I created a new folder on my C: drive and the icon changed to God Mode and I was able to access all of these settings from one place. Neat considering that occasionally I'll get lost trying to find a particular setting.
Here are the options located in this God Mode area:
-
Action Center
-
Administrative Tools
-
AutoPlay
-
Backup and Restore
-
Biometric Devices
-
BitLocker Drive Encryption
-
Color Management
-
Credential Manager
-
Date and Time
-
Default Programs
-
Desktop Gadgets
-
Device Manager
-
Devices and Printers
-
Display
-
Ease of Access Center
-
Folder Options
-
Fonts
-
Getting Started
-
HomeGroup
-
Indexing Options
-
Internet Options
-
Keyboard
-
Location and Other Sensors
-
Mouse
-
Network and Sharing Center
-
Notification Area Icons
-
Parental Controls
-
Performance Information and Tools
-
Personalization
-
Phone and Modem
-
Power Options
-
Programs and Features
-
Recovery
-
Region and Language
-
RemoteApp and Desktop Connections
-
Sound
-
Speech Recognition
-
Sync Center
-
System
-
Taskbar and Startmenu
-
Troubleshooting
-
User Accounts
-
Windows CardSpace
-
Windows Defender
-
Windows Firewall
-
Windows Mobility Center
-
Windows Update
Here is my screenshot:
I'm running 64bit Windows 7 Ultimate but as far as I know it should work on all versions. So this is how you do it.
1. Create a folder anywhere on your machine and name it “GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}”…without quotes.
2. Done! :-)
Currently rated 5.0 by 1 people
- Currently 5/5 Stars.
- 1
- 2
- 3
- 4
- 5