I am attempting to implement a reverse proxy using the RequestInterceptor from WCF REST starter kit. I am able to set the basic header properties and configure the calls. I am getting stuck with the following aspects:
Returning an appropriate response - my webservice can return text+xml, image or json. I am not able to send the appropriate response type. The Message.CreateMessage overloads are all SOAP aligned i.e. they accept only Xml constructs, so I am not able to send either JSON or image streams. I need to convert them into XElements - I am definitely doing something wrong here.
I also want the reverse proxy to be functioning well in the presence of cookies, gzip/deflate and SSL.
Based on the above requirements, do you think it makes sense to do this using REST starter kit? The Requestinterceptor was fairly easy to plug into, however the rest of the code is driving me nuts.
There is a mapping between both JSON and arbitrary binary content to XML which is used in messages for WCF (see some examples at http://blogs.msdn.com/b/carlosfigueira/archive/2011/04/19/wcf-extensibility-message-inspectors.aspx), so you can use Message.CreateMessage to create non-XML messages as well.
Having said that, it's really not intuitive to do that in WCF as of now. The new libraries in the WCF Web API - http://wcf.codeplex.com - provide a very nice way of intercepting / redirecting / bypassing the WCF pipeline especifically for HTTP messages. Also, it support multiple formats in a native way (i.e., without need to do some mapping to XML).
Related
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.
I'm building a WCF SOAP service at the moment. I will, of course, need some authentication on the service.
Reading this very helpful blog post says that to use the built-in authentication points requires that the endpoint use the wsHttp binding.
This would be fine if I could guarantee that users would be communicating with the service through a client based on the meta-data exposed by WCF (basically, something like a client written in C# with a web service reference). However, I can't guarantee this!
I will still need to allow users to communicate with just raw (unencrypted) XML.
So, questions:
Does the wsHttp binding still allow for raw XML input?
If not, would I be wiser to
Implement two separate authetication points? One for raw XML input and one for encrypted input
Or
Allow input from wsHttp to fall back on some in-method validation that would be shared with the raw XML input?
Is it wise to allow users to pass their credentials inside a raw XML request?
EDIT: It sounds like I miscommunicated or misunderstood something in my original post, so here I will clarify what I mean by "raw XML".
By raw XML, I mean just the SOAP packet and the accompanying HTTP headers - as I might send from soapUI or Fiddler. As I understand it, messages over the wsHttp binding are encrypted when a client is generated from the WSDL (for example, in C#).
If this is not the case, then how would I go about attaching the same sorts of credentials to a raw XML (for want of a better term) request as I do a request run through a client? Are they attached as HTTP headers? XML elements in the SOAP envelope?
wsHttp is a SOAP binding, which means that your content gets wrapped in a SOAP envelope, possibly with headers relating to the message and various WS-* specifications being used.
I would ask why you need to support raw XML? Most platforms today support SOAP messaging and the whole idea of SOAP is to provide interoperability between different platforms. On most platforms it is as easy to develop a SOAP client as a raw XML client. In most cases, it is simply a case of taking the WSDL and generating a client. If you want to use standard facilities like authentication and message encryption then this is a much better way to go.
There are currently no hooks to do interoperable authentication for raw XML. You will have to come up with your own mechanism to do this and it will be non-standard. For your web service users, this means it will be probably entail more development effort than if you just went with SOAP.
I am going develop a WPF windows based application. I want to work with Entity Framework Self Tracking Entities and WCF. I was wondering if using Json is possible/recommended? If yes, please assist me; is there any tutorial that can help?
You can use the DataContractJsonSerializer to serialize the messages. You will have to use a REST based service (WebHttpBinding) as SOAP mandates XML as the message payload.
You can tell WCF to use the DatcontractJsonSerializer on the service side by settings in the WebGet and WebInvoke attributes but on the client side you will have to manually use this serializer as REST doesn;t have a metadata standard and therefore you have to create the requests and manage responses in a more manual fashion
Here is a reasonable guide to using Json and REST support in WCF
However, what is your driver to using Json? WCF is much more geared to SOAP based interaction currently (although the WCF 4.5 WebApi is going to address that to quite a degree). As your client is WPF you don't seem to gain alot from using Json
I created a WCF project with one simple method that returns a pdf in a byte[] and a int (id #) and has username+password with a custom validator for message security and a SSL for transport security. Now the client tells me that he was assuming I was going to create a RESTful API instead. I don't have any experience with REST, but I've seen that you can create a REST project in WCF (which is what I'd prefer for interaction with the rest of my solution).
First, can you deliver a pdf the same way in a RESTful API? I set the int as an out parameter in order to return it to the client, can I assume an out parameter will function the same as well?
Second, can I use the same kind of security setup? I'm assuming the SSL will still protect the transport, but I cannot seem to find a good example or tutorial on basic security. I can use a different method of security if needed.
REST is different than SOAP or even WCF in that you aren't using cumbersome "envelopes" unfortunately those envelopes provide you with functionality like the authentication scheme you're using (and out params, etc.)
See Best Practices for securing a REST API / web service
You can go /w basic authentication + SSL for authentication. You must encrypt basic authentication though or else it is insecure. As for the out parameter, it seems that a composite XML based result like the following is one way to go:
GET
could return XML like:
<result>
<intValue>4</intValue>
<pdfByteString><![CDATA[bytestring...etc.]]></pdfByteString>
</result>
It actually does look like WCF does have some built-in functionality to help you out, this white paper should provide a decent intro:
http://msdn.microsoft.com/en-us/library/ee391967.aspx#Y1720
I'm looking at creating a data query WCF service over a slow satellite connection and I really like WCF Data Services. The problem I see is that HTTP is a very verbose format and since everything I'm doing is internal and .NET, is it possible to use NetTcpBinding instead to reduce some of the overhead?
Is this even possible? Advisable?
While researching this on my own, i ran across the MSDN article on Self-Hosted WCF Data Services. This article notes that you can host the service with DataServiceHost which still requires HTTP (it's derived from WebServiceHost).
But you can also roll your own host using IDataServiceHost. Here's an excerpt from the MSDN article:
For cases where the WCF host
implementation is too restrictive, you
can also define a custom host for a
data service. Any class that
implements IDataServiceHost interface
can be used as the network host for a
data service. A custom host must
implement the IDataServiceHost
interface and be able to handle the
following basic responsibilities of
the data service host:
Provide the data service with the service root path.
Process request and response headers information to the appropriate
IDataServiceHost member implementation.
Handle exceptions raised by the data service.
Validate parameters in the query string.
The article seems to suggest that MS has properly segrated data-service responsibilities from network interface responsibilities. If that's so, then I should be able to write a NetTcpDataServiceHost. Has anyone ever written a IDataServerHost? Any suggestions?
No, WCF Data Services are built on top of REST, and REST itself is very intimately and completely based on the HTTP verbs like GET, PUT, POST etc. - you cannot run those over NetTcp, since those are intrinsically tied to the HTTP protocol stack.
Maybe there are other options for you to reduce the data being transmitted? Tweak your objects - trim the fat, if you can - both on the number of rows retrieved at once, and the number of attributes/data fields transmitted. That's probably you're most promising approach.