WCF - quick response with status then continue doing longer process - wcf

I spent few days search on this case. I checked out all wcf asynchronous implementaions.
I wasn't able to find what I was looking for.
Below is scenario.
WCF is running to accept xml
WCF needs to response to user for success receiving xml and release
the request immediately
WCF then needs to do processing to save xml to database and parsing xml to
convert something else.
I don't want to use separate service to process above. I want to use one service to handle all 3 cases above.
I checked out asynchronous way of coding in WCF, but this doesn't release the request right away. What is the best practice for this? Is there any sample code I can use?
Thank you in advance.

I think you would be better suited to using a different technology. Maybe look at Windows Workflow Foundation.
You can host WCF Workflow Services the same way as you host a standard WCF service, the main difference is that you can create specific workflows that can continue after acknowledging receipt of the original message.
You do this by persisting the message and returning to the user. WF allows you to create actions that continue after sending response back to the caller.
Visual studio provides you with a design surface that allows you to drag and drop components to create custom workflows. Additionally you can also make calls to other services if required.
With .net 4.5 you can now use C#, in previous versions of WF you had to use VB.net.
You can read about it on the MSDN site here:
http://msdn.microsoft.com/en-us/vstudio/jj684582.aspx
Hope this helps

Related

Call WF Workflow from Browser

OK, I've searched the Internet for the answer to this and haven't found anything... maybe I'm missing the obvious here or just asking the wrong question, but...
How do you call a WF WCF Workflow just by it's URL with parameters? I have a Workflow xmlx, we'll call it DeepThought.xamlx, an operation named TheQuestion and I need to pass the parameter Answer = 42 to it.
I've tried http://localhost:8042/DeepThought.xamlx/TheQuestion?Answer=42 and just about everything else I can think of. I've scoured the Internet and even the wsdl but am either just flat out missing the answer or simply not seeing it.
I assume it's possible, otherwise, what's the point? Clues appreciated.
At least out-of-the-box this is not possible. The standard Receive
activity uses SOAP. I'm sure it's possible to implement a custom Receive but I guess it would be a non-trivial amount of work.
You can also take a look a the following questions. They are REST-related but still may give you some options (a community RESTful endpoint is being mentioned, no idea of its current state though):
RESTful Workflow Service Endpoints in WF4 / WCF
WCF Workflow Service REST interface
I ended up implementing the workflow as a regular activity (non service) inside WCF. This gave me the ability to use their parameters and pass them to the workflow directly. In the end, not too difficult to implement.

How do I create and Axis2 client

I've been given a WDSL file and have to create a web service client using axis2. I've been able to generate the CallbackHandler and Stub using WSDL2java. I've tried following this tutorial to create the Client http://briansjavablog.blogspot.com.au/2013/01/axis2-web-service-client-tutorial.html
I'm not sure if I implemented the client properly. It runs, but I'm not sure how you view any output results. I've never dealt with web services before. The Stub file that was generated contains so much code, how am I supposed to know what I should be calling? All tutorials I've found give example Clients, but I want to know what I need to look at to create my own.
If anyone has any advice or links to creating clients that are easy to understand, it would be appreciated.
I think that this probably went un-answered for a while due to the fact that the question is not clear and you probably need an introduction to Web Services and SOAP in general. If you are given the WSDL (or can pull it from a URL out there somewhere) then you are using the Web Service as a client - you have (from the post) already created the stub for client use. You simply need to use it. You are sending a request to the server (Web Service) and sending it the data that it requires (as the SOAP parameters that are laid out in the Web Service schema). Based on this SOAP request you will get a response. Your stubs that are created for the client act as the invocation and response points for your client.
So your question as to how do you test it: you decide what to do with the response as this is what you are coding into the client.
And about creating your own Web Service - you would need to start with a schema (often times you write your objects/data and the functions that you want them to perform and tools (like Axis2) will generate the server code (for Web Services and SOAP transport) on top of this.
So in your question, I think that you need to a) check out some Web Services books/online tutorials to figure out what it is, b) code your client to display the results and stuff - and just make sure that you are actually sending and getting responses from the Web Service, and c) also see what it would take to create your own Web Service (for whatever purpose you are planning the service to be established for, before creating your own.
Effectively I think that you just need to get your feet wet with Web Services in the first place. And the tutorial that you pointed out ( http://briansjavablog.blogspot.com.au/2013/01/axis2-web-service-client-tutorial.html) is excellent for anyone looking to get a web services client started - thanks for posting that.

Windows Workflow 4.5 Paradigm Questions

I've been digging into the technical details and implementation of Windows Workflow 4.5 as a beginner and having decent results. My question is more of a "why and when" vs. a "how to" question so bear with me.
I've taken a familiar concept to us all and abstracted the business logic into WF, namely the universal log on process. What I wanted to accomplish is having reusable logic that I can call from an MVC website, a Windows Forms application, etc. and have everything run through the same workflow and I have achieved that.
Now I have 2 conceptual questions as to "when" to apply WF and when to use code.
1 - Take simple validation as an example. I'm trying to login but I've passed an empty user name or password string. Obviously, I want to send a message back to the end-user "UserName Required" and "Password Required", which I've done. Now, the way that I did that is I have a validation class (FluentValidation NuGet package if it matters) but the important thing is I'm doing this in code. So, in WF I call my validation code via an ExecuteMethod and everything works just fine. My question is: Is this the wrong approach with a WF mindset? Should I be doing inline WF "If" Actions/Decisions and building up the validation messages inside of WF directly versus calling out to some chunk of code? I'm asking not just for validation but as a concept we can all relate to but more generally should I be attempting to put anything and everything I can into WF itself or is it better to call custom code? I'm looking more for best practice with reasoning from seasoned Software Architects with WF experience versus someone's opinion if possible.
2 - Picking up a workflow on another machine. So, part of the same login workflow activity requires a service method call. I've written the code and workflow in such a way that the workflow receives an In parameter of ILogOnService which has an interface method "AuthenticateUser". The concrete implementation I'm passing in calls out to an MVC4 Web Api post method, in async, to do a standard Asp.Net membership ValidateUser. Again, should I be calling this Web Api PostAsync from inside the WF workflow? If so, doesn't that tightly-couple my workflow to Asp.Net Membership and my particular service choice. It seems there are ways to get the workflow to a certain point and then resume the process on another machine, e.g. where a service is running, and continue the process but I'm not able to find good examples of attempting that.
Just looking for some guidelines and ideas from the pros at this technology but I will pick the most informative answer.
There is nothing wrong with using C# code to implement details of a workflow. In fact I always tell people that if they are using WF4 with just the standard out of the box activities they are probably doing things wrong. You really need to be creating, or have someone else do it for your, custom activities that model business activities for your business. Now if that means creating an activity that validates a login using the FluentValidation that is perfectly fine. Another time you might build a higher level business activity out of lower level WF4 activities, just combine them as works best in your case.
Calling a service with something like PostAsync can work well if you know the action is short lived and is normally available. However when you get into SOA styles you really want to start using temporal decoupling so one service is not dependent on another service being available right away. And when you get into temporal decoupling you really want to be using queues, maybe MSMQ or maybe another similar technology. So in that cas you really want to send a one way message with a response queue and have to workflow go idle and wait for the response message to arrive. This would reload the workfloe, possibly on another machine. Now that might not always be appropriate, for example in your login it would not be much use to grant the login a day later because the membership service was unavailable, but can result in very scalable and fault tolerant systems. Of course there is no free lunch as these systems are very hard to design properly.

Retrieving call source for a WCF service

I'm fighting since two days with a simple question : Is there a way to identify the source of a WCF call ?
I'm trying to find a realiable .Net property that will let the service know the address (URI) of the calling Web Service.
Especially in the case where two Web Services are hosted on the same machine.
Thanks in advance.
What about the calling client do you want to detect??
In .NET 3.5, you can fairly easily find the client's IP address - see Keyvan's blog post on that topic.
Is that what you're looking for?? If not, you'd probably have to add the caller information to the message (or the headers) explicitly for the server to be able to inspect that information.

View underlying SOAP message using vb.net

I have a VB.NET web service that calls a third party web service. How can I view the SOAP message generated by .NET before it is sent to the third party web service and how can I see the SOAP response before it is serialized by .NET.
When creating a standalone EXE, I see the Reference.vb file that is automatically generated, but don't see a similar file when my project is a web service. I have found lots of C# code to do this, but none in VB.NET.
Edit - Fiddler and TCP loggers are great, but will not work for my purposes. I need to be able to access the raw SOAP messages from within the application so I can log them or modify them. I need to do more than just see the messages going back and forth.
You can use fiddler or a tcp sniffer to filter and identify all outgoing and incoming traffic on your host.
This is if you want to see the xml request and response.
How about using an extension to allow you to examine the SOAP message?
Accessing Raw SOAP Messages in ASP.NET Web Services
http://msdn.microsoft.com/en-us/magazine/cc188761.aspx
I was trying to do the same thing and this seems to work for me:
Dim message As String = OperationContext.Current.RequestContext.RequestMessage.ToString()
I didn't think it would be that easy since most of the time ToString() returns the name of the class, but I tried it out and low and behold.
I know you asked this back in January so if since then you've figured out a better way let me know.
Please note that if you're catching the exception in a class that implements IErrorHandler then you have to perform this operation from within the ProvideFault() method instead of the HandleError() method because the context is closed before it gets to call the HandleError() method.
Hope this helps.