I have a XSD that I have generated classed from. After filling a class with data and serialize it, I want to send it to one or more specific clients.
My plan is to use SOAP, but the only way in my head to do this would be to create "www.example.com/message/custNumber" the same soap message in different URL's and let the client continuously look for new messages.
When the message is received at the client(s), they will need to send a acknowledgment back to the server.
Is this possible with SOAP? Or should I be looking at other ways for communication?
WCF has the possibility to dynamically set the endpoint of the service and with duplex message exchange pattern you can define that some messages require a ack back from the receiver.
Related
I need to integrate my C#/.NET application on an other system in our organization, which is exposing IBM WebSphere MQ endpoint. Im able to connect to MQ Queue and put a message into it, but I have a trouble with creating a payload of the message. The payload is required to be a good old SOAP message in form of a string. So I need to generate the SOAP message, but I dont have a WCF infrastructure involved in this case. All I have are XSDs for SOAP header and payload, and I think this should be enough to generate a message, but I dont know, how to construct a SOAP message without WCF.
I considered this:
Construct the SOAP message purely by myself using XmlDocument class. I dont like this idea.
Generate contract classes from XSDs and build the message in the way as in the case of WCF, but somehow serialize the message to a string and send it over MQ message.
Can you please point me to a solution using 2) approach? Or are there any other ways?
Thank you,
Michal
I'd like to communicate from my web app to an endpoint on a different tier via MSMQ. I've found examples of how to do this by binding with WCF, but not how to with WebAPI.
Why do I have to use WCF?
Are they any other alternatives?
Other than WCF's netmsmqBinding, you could also obviously use the more native System.Messaging.MessageQueue .Net classes to read and write directly from queues. However, it sounds like you are trying to pull messages from a client such as a browser?
Although you can send messages to MSMQ via Http, you can't receive messages over Http directly.
So TL;DR I believe you will need to write your own capability to receive messages via HTTP / REST etc, e.g. via a WebApi controller action which reads exactly one message and returns same. In doing so you will likely lose any transactional boundary across queue messages.
I want to interrogate a WCF service and I need a robust solution.
It's not acceptable that the service go down just because there is another program using the same port.
Port are technical details that should be transparent to the end user.
Which solution can I use?
Can I try so look for the service at two endpoint with different port numbers? Or help the conflict even using the same port?
I’m not entirely sure what you are trying to accomplish, but if you need to “abstract” your WCF Service / multiple endpoints from client applications then you may want to consider the WCF Routing Service.
The Routing Service is a generic SOAP intermediary that acts as a message router. The RoutingService is implemented as a Windows Communication Foundation (WCF) service in the System.ServiceModel.Routing namespace. The Routing Service exposes one or more service endpoints that receive messages and then routes each message to one or more client endpoints based on the message content.
In addition to the destination client endpoints associated with each filter definition in the filter table, you can also create a list of backup endpoints that the message will be routed to in the event of a transmission failure. If an error occurs and a backup list is defined for the filter entry, the Routing Service will attempt to send the message to the first endpoint defined in the list. If this transmission attempt fails, the service will try the next endpoint, and continue this process until the transmission attempt succeeds, returns a non-transmission related error, or all endpoints in the backup list have returned a transmission error.
I thougth the reason is bound to firewalls.. in enterprise level apps the single port should be opened.. so it's better to already know the ports.
we have a legacy middleware application and we want to implement WCF Adapter for it. lets say for the time being we would only be consuming WCF service. the middleware is capable of processing XML messages. we would like to get the message xml from middleware, forward it to WCF client. after getting the response we would like to reply the middleware with the response xml.
following are few of our concerns that we would like to be looked into.
we should be able to send raw xml instead of object based WCF invocation
upon receiving the xml after all the layers of WCF (this is important since the validations of xml itself should already be performed according to contract) we will be forwarding it to middleware.
our middleware implements classical webservices but there are various concerns with the datacontract serializer. one of those is object references. as we can already see that the reference of the object is kept by using id attribute in xml element. how could we catter that. are there any further things that we may consider for data contract serializer.
Middleware is concerned about the original message itself. we would like other message related properties like SOAP, WS-Security etc be handled by WCF proxy itself.
Does anyone has any idea how Biztalk adapter for WCF works
any feedback would be appreciated.
1) What you're looking for is known as POX (Plain Old XML). WCF supports this using the WebHttpBinding. Here's a good starting point.
It's not strictly speaking "raw XML" because WCF decides what to send, but what comes out is a plain XML document rather then a SOAP message. If you can't get WCF to send what you want even with something like POX, then it might make more sense to skip WCF for that component and simply open a socket to your middleware layer and send the XML directly. In that case you really can send exactly what the legacy middleware app expects. WCF could still handle the client-facing connections.
2) If you have a WCF service facing the client, WCF will parse the client message and give you some kind of object in your code (depending on the service contract). At that point it's up to your WCF service code to either use another WCF connection to contact the middleware, or as I mentioned open a socket and send the necessary request. But stripping off the WCF "stuff" is done for you before your service method will start.
4) That should be no problem. WCF and your code will handle that before sending anything to the middleware.
Hope that helps a bit. :)
I've got a simple WCF Web service that uses basicHttpBinding to make it SOAP 1.1 compliant. When called with a WSDL-derived proxy (by setting a service or Web reference), the service works great.
A business partner wants to call the service directly with the SOAP XML. I know how to provide that XML, but I'm not sure how to process the XML when the business partner submits the request.
Am I making this harder than I need to? Will the XML request call the service as though it were called through the proxy and will the response naturally make the request happy? Or do I need to do something extra to process the XML request and then hand something (what?) off to my service?
I know there are some similar questions on SO, but they all seem to deal with the issue of getting the XML, not processing it.
It should be sufficient to just send the raw SOAP message to the endpoint URL of the service. The WSDL-derived proxy just generates the SOAP from your objects and manages connection handling and transport (probably HTTP) details.
It might be possible that you need to add a SOAPAction HTTP header, depending on the service.
If you intercept the communication between your WSDL-derived proxy and the servcie (e.g. using TCPmon), you will see the SOAP message and the used HTTP headers.