views:

88

answers:

2

Hey guys, here's my requirement:

I have one central App which receives requests from other apps, does something, and then returns data to that App. In its simplest form this data would be an XML document.

Now, at design time, this central App doesn't know which other applications will be making requests.

Each time the Central App receives a request, it will also receive a URL, telling the central App its web service address (see below), so the Central App knows where to push the data to:

http://someapp1.com/UpdateData
http://someapp2.com/UpdateData

Now, I'd like to use either SOAP, or some kind of RESTful implementation, preferably not WCF.

My questions are these:

  1. With SOAP can I dynamically, at run time, change the service URL, if the interfaces are all the same?
  2. If I can, then how would I go about posting large amounts of XML in a RESTful way?
+1  A: 

Is the work of the Central App some sort of very long-running process? Otherwise, why wouldn't Central App expose web methods that simply returned the results as a response, rather than initiating a new call?

someapp1 calls Central.GetMyData(param) ... Central processes ... someapp1 receives SOAP response from Central

This will also help to decouple your system, which is now set up so that lots of apps know Central's API and Central knows what it should send to each of these other apps.

Jay
hey jay. yeah, Central App is a long running process...it might run for hours, or days. Its essentially a queue which receives tasks, and then deals with them one at a time. It then returns, maybe days later, a result.any ideas? cheers
andy
Okay, it looks like Michael responded about changing the endpoint addresses, which is definitely doable.As to REST, you're apps are only going to be RESTful if http://someapp1.com/UpdateData refers to a distinct set of data, and a GET request gives back the exact same information that a POST puts, every time. If, on the other hand, UpdateData is basically a method that accepts whatever XML Central gives it, you're not RESTful.That is totally okay, though. REST isn't always what one needs...
Jay
...(cont.) You may want to look into the Message class to encapsulate your return data. It gets you into grittier territory conceptually. It sounds like you may also want to stream your data, rather than buffer it. This post is helpful on both counts: http://weblogs.asp.net/cibrax/archive/2008/06/10/streaming-large-content-with-wcf-and-deferred-execution.aspx
Jay
+1  A: 

Hi Andy

Point One) It is certainly possible to change the endpoint to which a web service proxy is talking at runtime. I believe it looks something like this...

ws.Endpoint.Address = new System.ServiceModel.EndpointAddress( newurl )

In you case obviously your 'Central App' is going to be invoking the proxy as it sends back the data to your 'requesters/recievers'.

When you requester/reciever is putting in a request, it will be using a proxy to invoke the central app but i guess in this case, it doesn't need to be dynamic (only one 'central app' right?)

Point 2) Not sure what the cleverest way of doing this is. by default of course, the messages you send/recieve from a WCF web service are always XML. If you want the service contract to remain the same, you are going to need a wrapper object to contain the data. I suppose you could try creating an object that has a 'payload' member that can hold your data.

Hope this helps

Michael

Michael Dausmann
thanks michael, yeah, that definately helps. You are right that there's only one Central App...so that won't change. So, with the EndPointAddress changing, is that within the SOAP model...I'm kinda resisting getting into WCF...? cheers
andy
just noticed there was an error in my question. I meant to say "not WCF". thats been fixed now. cheers
andy
ah ok, thats definately WCF code there dont know the SOAP equivalent off the top of my head.
Michael Dausmann
Ah, NOT WCF. You should know that WCF uses SOAP messages by default. I've never used WCF to move anything other than SOAP envelopes, in fact.
Jay