I have a qooxdoo web application which should be able to request data from a WCF web service. The WCF service uses SOAP. I'm currently looking for a way to set up the communication between my qooxdoo application and the WCF web service.
Is there a way to get this done? I saw that qooxdoo is supporting REST and I'm looking for something like a SOAP module in qooxdoo.
Thanks in advance!
There's an ancient contrib, probably unmaintained, at http://svn.code.sf.net/p/qooxdoo-contrib/code/trunk/qooxdoo-contrib/Soap/0.5.1/. You might not be able to use it right away, but I think the source code there will need just a few changes to become usable.
Related
I work in a company that is only using WCF and i am trying to introduce service stack. Now i understand we are better off using the service stackclients that wcf clients but for some of our stuff and to keep people happy that will not always be possible. Can anyone provide a basic example of a ServiceStack service that can be added as a client into a VS2012 project using the add service reference inside visual studio as you normally do for a WCF service? Basically is there a way to make ServiceStack seem like a WCF service to people that don't know about ServiceStack?
If i can show this i think i can convince my company to make the switch but if not it will be difficult as everything else is WCF based. We are already using the ServiceStack clients to hook into other online websites so it seems a good time to try to convince them to move to the service stack services and clients as long as they feel they can fall back to the WCF client if needed.
Provided you adhere to the SOAP guidelines and limitations in ServiceStack you should be able to add a Service Reference by pointing the client to the ServiceStack wsdl at /soap12, e.g:
http://servicestackbaseurl/soap12
You can also find a link to the soap 1.1/1.2 wsdl (and XSDs) on ServiceStack's /metadata page.
I tried using JIRA's REST API but the function that I needed wasn't there and found it at JIRA's SOAP API. A newbie like me wants to know if you can use JIRA's SOAP API in a VB.NET desktop application? Thanks!
Absolutely. The point of a SOAP service is to allow access to the data and functionality of application from another application regardless of the language it is written in. All you need is something in your program that understands how to talk to and work with a SOAP service.
I have no doubt that a VB.NET application can talk to a SOAP service without issue, but I am not a .NET programmer so I can not provide any specific guidance on how to do it.
What you will want to search for is "Consuming SOAP services with VB.NET". I did that myself and came up with some god looking tutorials.
http://www.codeproject.com/KB/vb/vbwebservice.aspx
http://www.vbdotnetheaven.com/Uploadfile/SrinivasSampath/WebServiceusingSOAPToolkit11242005002126AM/WebServiceusingSOAPToolkit.aspx
http://visualbasic.about.com/od/learnvbnet/a/LVBE_L6_3.htm
Like I said, I think everything you need will be built into the .NET framework. I don't think you will need to download anything additional or include extra libraries.
i'm about to begin a WP7 project. i currently have a WCF REST service deployed on my LIVE servers, and my Android and iPhone clients are happily consuming this. how do i get my WP7 to communicate with my REST service? The server side is working fine and well, and there is no issue there.
what i thought i would be able to do was simply add my client library (compiled in SL) with all the interfaces, datacontracts etc, create a ChannelFactory, ensure the web behavior was on in the client and yay! away we go. this doesn't seem to be the case however. certainly i can't use the interface created because of the WebGetAttribute reference :S
what is the reccomended way? i would prefer to consume my service in the same way as the other services do for consistency, so i don't want to make new (and more verbose communication) bindings and simply expose the same service over a different endpoint. similarly using WebClient / WebHttpRequest just seems a bit backward: certainly we don't have to parse the response for the other types of bindings available, why would we for this?
any suggestions? basically i want to write as little code as possible to connect the client and the server (ideally as much as normal WCF communication would take) and would prefer to communicate with a channel, since there'd be no parsing or deserializing the JSON response on my behalf.
surely this is possible? most people working on mobile applications have chosen a REST service to communicate with, seems a bit odd that microsoft's mobile solution wouldn't neatly integrate with its own server side solution! i really hope i'm just stupid and have missed something quite glaring.
I believe at this point RESTSharp is your best option.
Another REST Client library: Spring.Rest
I am going to need a web service that receives a string via HTTP POST and processes it without any response to the client. However, since I'm not the one making the client (which will be cell phones) I am unable to use a generated client class to consume the service. The service would also need to be self hosted in a regular Windows service, if that matters.
As I'm not too experienced with web services nor WCF, I am frankly unsure if I can or should use WCF for this, but as it's the only type of web service I'm at least a little familiar with I figured it would be great to start out with one if at all possible.
I've been googling around quite a bit but haven't been able to find any good references to this, so I'd also be very grateful if someone has a link lying around to someplace that discusses it.
I think you need WCF Restful service with one way operation. Following link might help you:
A Developer's Guide to the WCF REST Starter Kit,
Folks,
I'm building a pretty standard workflow that I want exposed via a WCF endpoint - I'm using the "WCF Service Application" project template and I've got a .xamlx service. This is a very simple document interchange workflow service - I want consumers to POST me a blob of XML as the body of an HTTP post (with HTTP headers containing authentication tokens). In response, these consumers will get a blob of XML containing the reply. 2 goals for me using REST/POX here are the document/message-based nature of the interaction AND I want to make client development easy for non-.NET environments (especially limited environments like Silverlight and iPhone).
I don't really see how to make this possible using out of the box features (unless I'm missing something). Does anybody know how to create a RESTful (or even REST-ish, I'm not picky) endpoint for a WF4 service-hosted workflow? Any info leading in the right direction here would be great.
There is an unreleased item on CodePlex to cover this, which includes source code. Also see this SO answer which contains another idea for achieving this.
If you'd like to see the CodePlex activity released, please up-vote the UserVoice request.
Using a REST Pass-Through Service
As #Maurice mentions, you can also treat the WF service as a back-end service and expose a REST service that simply calls through to the WF service.
This method is a bit clumsy, but has the advantage that it doesn't use anything unreleased or really complicated.
If the back-end service runs on the same machine as the REST service (which is probably what you'd do), you should expose the WF service using the named pipes binding. This binding is fast, but only works when the caller and callee are on the same box.
A further thought: your REST pass-through service is blocked while the back-end service is being called. If your WF service is not very fast, you'd benefit from making your REST service asynchronous so it doesn't block a thread pool thread while the WF service is being called.
There are no out of the box activities that will allow you to use REST with WF, the Receice is pure SOAP.
You can either build a custom REST Receive activity and use that with your workflow. Depending on your needs this is going to be quite a handful to a lot of work. The easy option is use use a standard REST WCF endpoint and convert the REST data to SOAP, pass rhe request on to the workflow, and do the reverse on the result message.