Simple question (details follow) : how to use named pipes, without soap serialization, i just want to have on method and read the byte array myself. I'm trying to implement a service that does not rely on XML, through named pipes.
Few weeks ago, i wrote a service using wcf and web sockets. This service, to deal with non .net software, use a custom binding with a really simple contract :
[OperationContract(IsOneWay = true, Action = "*")]
Task Message(System.ServiceModel.Channels.Message message);
and the callback :
[OperationContract(IsOneWay = true, Action = "*")]
Task OnMessage(System.ServiceModel.Channels.Message result);
In this case, i just read the byte array and deserialize using protobuf.
I've got another service on the same machine, and i want to improve performence using the protobuf deserializer. This service is already exposed with named pipes (with our former contracts).
With the new websocket server, and the protobuf serializer, i would like to implement it on the second service. Looking at protobuf endpoint behavior, it seems that they override the XmlObjectSerializer, but it seems that it still use some xml.
Do anyone have an idea on how to do this ?
Thanks
Related
I have inherited a web service built to receive calls from a third party system, "System A". It was a POC that may not have any active functions calling it and I suspect it was only tested from SoapUI or the like and never from the application it was designed for.
When System A is configured to call it, the service is called but the payload, one complex-type parameter, is null.
I have two other web services written years ago that accept calls of the same type from the same function of System A. Pointing System A to either of these services results in the parameter being supplied. Contracts and WSDLs look very similar and the only variations I see (like differing namespaces) seem to vary between the two services that do work.
What would cause a web service to not receive the payload in the call?
Related, where should I look to find it? The parameter is getting dropped between System A calling and the web service code itself getting hit. I've checked the trace logs but see nothing that I recognize as useful.
namespace MyNamespace.StandardNoteReceiverService
{
public class StandardNoteReceiverService : IReceiveNoteService
{
public StandardNoteReceiverResponse ReceiveNote(ReceiveNoteData standardNoteReceiverRequest)
{
string x = standardNoteReceiverRequest == null ? "NULL" : "ok";
LoggingLib.Log($"Service called. Paramter status: {x}");
return NoteReceiverServiceLayer.ReceiveNote(standardNoteReceiverRequest);
}
}
}
which implements
namespace MyNamespace.StandardNoteReceiverService
{
[ServiceContract]
public interface IReceiveNoteService
{
[OperationContract]
StandardNoteReceiverResponse ReceiveNote(ReceiveNoteData standardNoteReceiverRequest);
}
}
It turned out to be the parameter naming. Once I changed the name of the parameter to be the same as the name used by the services that are working, it began receiving the data.
public class StandardNoteReceiverService : IReceiveNoteService
{
public StandardNoteReceiverResponse ReceiveNote(ReceiveNoteData NoteData)
{ ...
How did you build “System A”? Is it a WCF Web HTTP service or an ancient soap web service? How does the client call the service and send the parameter? I think it may be that the format of the parameters sent by the client is incorrect. In the Rest-style service created by WCF, using complex objects as parameters to pass data may not always receive the value of the parameter on the server because of the format of the parameter.
Get the object is null using JSON in WCF Service
While in the WCF SOAP web service, the invocation is completed with a client proxy, the parameters are strong-typed. If the server always gets null, it might be caused by other issues.
I suggest you create a minimal, producible example so that I can try to offer a workaround instead of offering speculation of this issue here.
Feel free to let me know if the problem still exists.
I have Restful WCF service which will be used to read the data push by another Restful service hosted somewhere on the internet. I have to expose one method to read the Json data push by the other service.
[ServiceContract]
public interface ITestService
{
[OperationContract]
[WebInvoke( Method = "GET",
ResponseFormat = WebMessageFormat.Json )]
string GetData(string JsonData);
}
Is it right to receive data in string parameter or should i make the DataContract (Class) to receive the Json data. I know the structure of the Json data push by other service and Is it ok to make Get Method ? Also Push service can send bulk of data at once. how can i restrict it so my server works fine even with bulk data.
I personally don't like the default JSON handling in WCF and thus we use Newtonsoft.Json! We define the data values as string and then check the incoming data versus a JSON Schema file. In my opinion it depends on how extensive you use WCF. For use we use WCF primarily for tcp connections where we use the defined Data interfaces. The REST api is just for internal debugging and not exposed. So a clearly documented api isn'T that important. By defining proper data contracts you can utilize the automated docs WCF generates under the root url of the restful service + /help.
Anyway you should NOT use an HTTP GET to receive push notifications.
POST/PUT would be an appropriate endpoint for a push notification. The following article explains quite well how and why to define REST routes the way to be:
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#restful
Hope that helps a bit.
I have a WSDL definition for a SOAP service and I have successfully generated *.cs file from it using SvcUtil.
Implementing client is quite straightforward - I just need to call the necessary functions from the generated *.cs and that's it.
Implementing server seems more complicated. As I understand I need to implement an interface from the generated *.cs and then use some magic to turn it into the web server.
But I don't need a new web server, I already have a web server written in C# which already has many functionality unrelated to the SOAP service that I need to implement. I don't want to create another web server but I want my SOAP service to be just a part of my existing application (server), that is my server can answer e.g. requests http://example.com/request1, http://example.com/request2 etc. and I want this SOAP service to be just http://example.com/request3.
Since HTTP is already handled by my server I don't need .NET to handle it for me, basically my server can accept client connections and call the necessary handler based on the URL. I have a handler for SOAP request which looks approximately like this:
MyResponse HandleSOAPRequest(MyRequest request)
{
// 1. parse soap message from request.body
// 2. process it
// 3. generate response, serialize it in SOAP format and return it
}
The question is - can I rely on WSDL definition and .NET libraries to do it?
Currently I'm parsing SOAP request using XDocument and manually extract fields from it and serialize using simple string concatenation. Using .NET built-in functions to serialize or parse XML doesn't work. That is if I try to serialize response from an object of the class defined in the generated *.cs file then produced XML is different from what is expected by the protocol, similarly, if I try to parse request as an object of the class defined in the generated *.cs file I get error because XML parser expects different format. This applies to both the SoapFormatter and XmlSerializer.
Since .NET can implement client this means that everything that is necessary to parse and serialize SOAP messages is already implemented, I just need to figure out a way how to use this functionality.
The documentation for ServiceModel wasn't very helpful.
The easiest way would be to start the service via the ServiceHost:
ServiceHost host = new ServiceHost(typeof(YourService));
host.Open();
(I assumed here the configuration will come from the app.config and will not be setup in code like in the linked example below.)
How to: Expose a Contract to SOAP and Web Clients
The only drawback of this is that the application has to run with admin rights or otherwise a weird cofiguration is necessary.
I'm trialling out ServiceStack and loving what I'm seeing so far. However I've run into a bit of a brick wall.
I have a system retrieving data from another system via web services - a service at both ends. These two systems are from different vendors - so I have no control over changing them - and are configured to talk to each other via WCF web services. Let's say "Lemon" calls "Orange" to get some information about a customer.
The way we implement these two systems is slightly different to what the vendors planned - we point their service configuration to our intermediary service - let's call it "Peach" - which goes off and does some other things before returning the information. For example, "Lemon" calls what it thinks is "Orange" but is actually our intermediary service "Peach" using the same method names. "Peach" calls "Orange" for the customer information and for example overrides the email address for the customer with something else before combining all the information appropriately and returning it to "Lemon" in the format it was expecting.
I would like to get "Peach" using ServiceStack. However it's responses needs to be identical to a WCF service returning via wsHttpBinding. Is this possible with ServiceStack? Would it involve overriding the Soap 1.2 type?
Thanks for your help!
If ServiceStack's built-in SOAP Support doesn't return the response you're after, you may need to return the exact SOAP response you're after as a raw string.
Raw Access to WCF SOAP Message
To access the WCF's Raw Request in your Service you can use the IRequiresSoapMessage interface to tell ServiceStack to skip de-serialization of the request and instead pass the raw WCF Message to the Service instead for manual processing, e.g:
public class RawWcfMessage : IRequiresSoapMessage {
public Message Message { get; set; }
}
public class MyServices : Service
{
public object Post(RawWcfMessage request) {
var requestMsg = request.Message... //Raw WCF SOAP Message
}
}
Creating custom WCF Response
Some level of customization is possible by creating a custom WCF Message response and returning the raw output as a string, e.g:
var wcfResponse = wcfServiceProxy.GetPeach(...);
var responseMsg = Message.CreateMessage(
MessageVersion.Soap12, "urn:GetPeach", wcfResponse);
return responseMsg.ToString();
Otherwise you may need to use a HTTP Client like Http Utils to POST raw SOAP to the WCF Service and return the raw string Response.
This question isn't specifically related to WCF. What WCF returns is not a construct of WCF, it is returning a standards based response as specified by the WS* standards. http://en.wikipedia.org/wiki/List_of_web_service_specifications lists many of the standards.
Your question isn't specifically making ServiceStack emulate WCF, it is for ServiceStack to return responses adhering to existing published standards. Standards that WCF has already built in with the WsHttpBinding configuration.
What I basically need is a small console application that listens on port 80 and is capable of putting JSON objects around.
Receiving value types, objects and List<T> (or array) from a JSON client and converting them to .NET classes
Sending value types, objects and List<T> to the client
Outputting some information to the console
Performance is not a problem as I expect about 20 - 30 request per hour.
I don't want the IIS or Cassini Web server as a requirement on the client side. Only my console application and dependencies.
I already tried servicestack.net which looks very promising and has an example for a console host. Howevery I din't manage to get JSON out of the console host (only XML).
Any ideas how to use servicestack.net or alternatives are welcome.
By the way: The client will be an Android phone and since my current approach IIS + WDSL + kSOAP 2 (on the phone) causes more trouble than it solves, I really want to try a lightweight standalone JSON solution.
Maybe I'm incorrect, but I suppose you could use WCF hosted in a console application.
The Kayak project does pretty much exactly what you want to do. It's very lightweight and very powerful. Check out some of the examples (taken directly from the project page):
public class PostAPI
{
[Path("/widgets")]
public Widget[] GetWidgets()
{
return Widget.GetAll();
}
[Verb("POST")]
[Path("/widgets")]
public void CreateWidget([RequestBody] Widget w)
{
w.Created = DateTime.UtcNow;
w.Create();
}
}
public class Widget
{
public string Author;
public string Text;
public string Created;
// (Methods would be here...)
}
It can automagically serialize and deserialize between JSON objects and CLR objects and accept routes as well as both POSTs and GETs. Finally, it includes a built-in server that you can easily throw into a console application.
You could use a HttpListener to hande HTTP requests in your application. You would have to handle the JSON serialization yourself, but that may not be a problem?
Depending on which framework version you are using you could use either the built-in JSON serialization support or you could use the Json.NET library to do this. In either case it should be easy to detect the requests and to return a JSON response.