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
Related
There is an existing application which consumes a webservice. Now I want to make a new webservice for this application. I have no access to the source of this application. In the existing application it should be possible to just change the wsdl url definition and everything works as before.
So at least, I'm trying to prey an existing webservice. In that case the returned soap response must be the same as the existing one.
Now my question: How can I change the wcf soap response xml?
For example if we create a new wcf project in VS we get the Service.svc. In this project there is a built in wcf test client:
With MessageContracts I can't accomplish what I want.
With the IClientMessageInspector implementation I'm able to hook up the response soap xml and do changes but this only works from a separate client project. I want access this soap xml response in the same webservice project and do changes before it gets sent out to the wcf test client window.
Any ideas on how I can do this?
You can use the IDispatchMessageInspector to modify the outgoing response.
https://msdn.microsoft.com/library/ms733104(v=vs.100).aspx
I.e. IDispatchMessageInspector is what is used to inspect (and modify) the messages on the server (applies to both incoming and/or outgoing messages).
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.
I need to build a backend for an iPad app done in Objective C. I have two choices for that, one being Java and other C#.
With a backend built in either one of those, what options do I have to put the backend and frontend together? One option could be to use XML messaging. What are the other options?
Also what is the standard way of doing this? i.e. if we have an objective C frontend, then what should the backend be in and what communication mechanism should be used between the two?
I did some reasearch and am sure that either of Java or C# would work, but I could not find much information on how to make them work with the frontend? (Please bear in mind someone else would be doing the frontend)
Thanks.
You have a few things to consider. Wire protocol and Message protocol.
Wire Protocol:
This will contains things like the Message Id, Sender, Subject, Type, Timestamp, Message Size, etc. This is just as important as the Message Protocol. In order to recommend a Wire protocol I'd need to know more about your system. If you want a simple Wire protocol that will work on all those platforms you can take a look at STOMP. It is a simple ASCII based protocol for transmitting messages. It can be useful for debugging messages etc. ActiveMQ and RabbitMQ are Brokering systems that supports STOMP. I prefer RabbitMQ.
Simple STOMP message:
SEND
destination:/queue/a
content-type:text/plain
hello queue a
^#
You can also use HTTP as a simple wire protocol. It is simple and ASCII based like STOMP. Plus SOAP typically uses HTTP as it's transport protocol. SOAP also typically uses XML for it's message format to encode the Envelop, header and body of a message.
There is also JSON-RPC.
Message Format:
Most of the information in the Wire Protocol is used to determine where the message goes, if it got there, what type of information is in the message etc. Generally it is only used by the messaging system you put in place to send and receive messages. What your business logic is interested in, is the message content itself. You need a way to encode that content that both sides understand. There are plenty of choices for this: JSON, XML, Google's protobuf (binary).
I would have a hard time recommending any of these without more knowledge of what you need to do. They each have their own strengths and weaknesses.
Real-world mapping for wire and message protocols:
UPS, US Postal, FedEx = wire protocol
letter from mom, loan application, birthday card = message
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.