3

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.

  1. we should be able to send raw xml instead of object based WCF invocation
  2. 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.
  3. 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.
  4. 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.
  5. Does anyone has any idea how Biztalk adapter for WCF works

any feedback would be appreciated.

Mubashir Khan
  • 1,464
  • 1
  • 12
  • 17

1 Answers1

1

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. :)

Community
  • 1
  • 1
Tridus
  • 5,021
  • 1
  • 19
  • 19
  • your answers look to have potential. but i have further things to discuss with you. 1) webhttpbinding looks good but we can not force WCF Server to change to this particular binding for us as that could be external system. a bit of relationship could be explained as (Our Middleware)<->(Our WCF Adapter)<->(External WCF Server). and yes socket is our last option. but socket will always be not the answer. we have to cater MSMQ and named pipe bindings as well. 3) datacontract serializer is very important and what should we do with that. – Mubashir Khan May 12 '11 at 04:34
  • I don't know enough about 3) to help you out, sorry. :( In regards to 1), you'd use webhttpbinding when talking to your middleware. The external facing side of it can use whatever binding it's currently using or what you need. The two don't have to be the same, and translating between them is easy. (Your service takes a request, opens a client connection to the middleware, and sends it over. WCF handles the formatting.) If the requirements are overly strict though, sockets to talk to the middleware might be the best way to do it because you won't have to try and hack anything. – Tridus May 12 '11 at 12:58
  • awarding you the points as you have answered most of the questions – Mubashir Khan May 16 '11 at 12:26