Trying to decide if I need to implement a WF service or just stick with a WCF service that simply invokes a workflow and returns the result.
I dont need correlation handles, or any need to pause the workflow somewhere in the middle of its execution. It just merely needs to execute a workflow and return the result. Also, I might want to add a few methods to the service that do not involve workflows at all. So is there benefit one way or the other, or is a WF service just a pretty wrapper for exposing a workflow as a service?
I would recommend that you do not go for WF service if you don't need the bells and whistles. The WF Service really puts you into an enterprise-oriented use case straitjacket. If that's not where you're going then go for a looser integration with WF.
My two cents.
Related
Its been proposed by one of my team that we implement WCF routing service to simplify the configuration of our service architecture. I understand the concept, but want to make sure there are no hidden gotcha's, bottlenecks or other issues before we move forward on it.
We use custom service classes, error handlers, dispatchers, etc. I need to make sure the routing will not interfere with these.
Can I get some general feed back on its viability/complexity?
We are migrating set of WSE services to WCF platform.
The new WCF services are called over secured HTTP. (https)
I want to invoke an operation contract of one WCF service from another. Both the services are mostly hosted in the same IIS, but they can be on separate IIS server.
Do I need to take care of some things (which i obviously do not know at present) in this scenario?
Is there any special calling mechanism in this case?
Does calling mechanism change when call is synchronous and when it is asynchronous?
Can you suggest some type of binding which is readily available in this case?
1.) If the services are on the same box, use named pipes, unless you have any compelling reason not to, to communicate with each other. While WCF proper doesn't care about what you're doing as long as the address, binding and contract all match up (see what I did there?), .NET will when it comes to making network connections. The fewer you use, the better. (see http://msdn.microsoft.com/en-us/library/fb6y0fyc.aspx for more details)
2.) As stated in #1, if they're talking on the same box, use named pipes unless there's a good reason not to.
3.) Can you provide a little more detail on what you mean by this or what you're planning on doing? A lot of this is built out for you, so assuming you're familiar with implementing async methods and using async callbacks, the short answer is yes, it's different than calling an operation synchronously, but that's to be expected. Or do you mean IsOneWay = true? If that's the case, the calling mechanism is the same but there can be a number of other gotchas (e.g. faults)
4.) Named Pipes on the same box, BasicHttp otherwise (unless you need any of the additional features from WS).
but they can be on separate IIS server
In this case, you either can't use Windows authentication (if you were using it) or you have to set up some special delegates stuff on the domain to make it work. Windows Authentication won't "hop" between different servers. Here's some info on that, there's a lot of reading out there on the subject.
If they stay on the same server or you're not using Windows authentication, then it shouldn't be a problem.
Does calling mechanism change when call is synchronous and when it is
asynchronous?
Shouldn't matter, it's all the same on the service end. I will say that if the client calls X and X calls Y, X might as well call Y synchronously because it can't return to the client until Y is done anyway. (If X calls Y and Z, then X making async calls may make more sense.)
Can you suggest some type of binding which is readily available in
this case?
If you were using WSE before, then BasicHttpBinding is going to be the one closest to what you were doing and will look pretty familiar in what it outputs. It's also the simplest one to work with.
There shouldn't be anything special needed just because a WCF service method calls another WCF service. A WCF service doesn't "care" what other application types are calling its methods so long as they use the correct service contract, data contract, endpoint, and binding settings.
Just make sure that both service methods return promptly, and don't cause execution to block for long periods of time.
We have a multi services application.
We have moved a method that involves a DB access to a separate component that is exposed by a WCF endpoint.
We have more than one service that need to use this method.
The dilemma is what to use:
A WCF call to the method.
Call directly to the method, resolved by our DI engine.
The system performance is a critical issue.
So what do you think is better?
Using WCF to make the cal
Reference the required service and call it in-process using the DI engine.
Thanks Or.
If performance is critical, referencing the service component and calling directly the DB without going through all the WCF layers and serialization processes will be faster but less robust. If you decide to change the implementation you will need to recompile the client application as well. My advice would be to measure the performance of the WCF service call and if you are happy with the results leave it that way.
Assume a situation where a data will never be queried directly. AKA, there will always be some filtering logic and/or business logic that must occur.
When is a good reason to use data services outside of ajax/js?
Please don't site this page http://msdn.microsoft.com/en-us/data/bb931106.aspx
Your essentially asking what layer of abstraction should I use, WCF Data Services is built on top of WCF and aims to simplify the process of creating a REST based service that is consumable by anything on the web. It takes away a lot of the plumbing and configuration required to do this with a standard WCF service. The querying feature is another big plus and something that is difficult to get right with standard WCF.
So in short:
If you want to quickly build a loosely typed service that wraps an existing data model and enables querying support give WCF Data Services a go.
If you want full control over the service contract or the flexibility of exposing the service over any protocol, stick with plain old WCF.
My team owns both the WCF service and the Silverlight 3.0 application that will be consuming it.
We do not want to use svcutil to generate proxies as it adds complexity to the development process. We've been down that road before and we're not doing it again.
I've successfully used the ChannelFactory on a WinForms app and I'd like to use it again on this project. The difficulty seems to be that Silverlight expects Begin... and End... methods on the WCF service itself. I can understand that Silverlight might want to make the call asynchronously on a worker thread, but why does my service contract have to change to support this?
I feel like I'm missing something important here, but it's not obvious to me what it is.
Is it really necessary to change the service contract of a WCF service just so it can be consumed by a Silverlight app?
Well, you need the 'Begin' and 'End' methods on the interface so you have something to call.
That said, the sync v async is a 'local' thing, you can have the server have sync contracts (for the implementation) and the clients have the equivalent async contracts (for Silverlight). This means two different interfaces (or two copies of the same interface that just differ in AsyncPattern=true, if you think of it that way). But basically it's the same "contract" just projected into two different CLR interfaces to provide two different programming models for supply/consumption.
(Does that 'help'?)
(See e.g.
http://blogs.msdn.com/mjm/archive/2005/05/04/414793.aspx
which starts with two CLR interfaces that describe the exact same contract, but offer two different programming models for that contract.)
Although I am using the generated proxy for my current project, I found this document to be helpful if I were to create my own proxy:
Understanding WCF Services In Silverlight 2
You shouldn't need to change the service contract for the WCF service to be consumed by Silverlight.
In order for the silverlight UI to remain responsive, there is a design decision that silverlight should only support asynchronos calls.
For using WCF without svcutil have a look at this video: http://www.dnrtv.com/default.aspx?showNum=122