Can I get the response headers from a RemoteObject request? If so, how?
I am in the process of writing an application in Flex 3.3, using the Cairngorm framework, for deployment as an AIR application. The application heavily utilizes RemoteObject services to get data from a web server.
Each of my service delegates extends a common class which provides a method for calling service methods on the RemoteObject.
So, where I previously used
ServiceLocator.getInstance().getRemoteObject('myService').myOperation.send();
I instead use
this.send('myOperation', 'myService');
I use this method instead of calling the RemoteObject operations directly because this method adds another, global, responder to the operation call. This extra responder analyses data in the headers of reponse from the server.
Or at least it should -- this is where the problem is. In the result data (event as mx.rpc.events.ResultEvent) the headers property is always null despite the headers definitely being sent from the server.
Thanks
Unfortunately response headers are available only for URLLoader and only when using it in an AIR application:
Access HTTP response headers in for flash.net.URLLoader object?
Related
I'm using SignalR 2.2.2 Asp.Net 4.5 Web Application. I want to access the current http response object of the client caller but don't know how. How do I reference the response object? I've tried Context.Request.GetHttpContext().Response but it errors out saying "It does not exist in the current context". Can someone please assist and point me in the right direction.
SignalR does not let the user write directly to HttpResponse Stream for a couple of reasons and even if you found a way to do this it is not a good idea:
when using WebSockets transport SignalR uses webSockets to send messages so writing to HttpResponse would not work (and is not possible)
SignalR uses its own JSON based protocol if you write anything directly you will most likely create invalid SignalR messages which the client will not be able to process
If you want to send PDFs over SignalR you will need to be able to save it to a stream (e.g. MemoryStream) and invoke the client with an array created from this stream. (Note that the version of SignalR you are using is using JSON based protocol so sending binary data will be quite inefficient - it might be better to use SignalR to let the client know there is a PDF they can download and then the client would download it using e.g. HTTP GET request)
There's one point in ASP.NET Core that I believe I didn't fully understand yet and that is the idea of request features. As explained in the docs:
Feature interfaces define specific HTTP features that a given request may support. Servers define collections of features, and the initial set of features supported by that server, but middleware can be used to enhance these features.
My initial understanding about this was that request features are all things a server should expose to be used on the application pipeline. That is, behaviors that a server should perform like sending a file.
On the other hand, there's, for example, the authentication request feature. Now, I'm not sure authentication falls into this category. It doesn't seem like some server behavior that the application should call, but rather, a concern of the application itself.
This makes me wonder what really makes something be a request feature. So, what makes something be a request feature in ASP.NET Core? Is my initial understanding wrong? What is behind the decision of making something a request feature?
My initial understanding about this was that request features are all things a server should expose to be used on the application pipeline. That is, behaviors that a server should perform like sending a file.
That's one use of http features. It's also a way to augment or light up behaviors on the HttpContext, like buffering, send file, authentication, websockets.
Middleware can also add features specific to that middleware, you can see examples of this:
The exception handler middleware flows the exception that occurred via a request feature - https://github.com/aspnet/Diagnostics/blob/dev/src/Microsoft.AspNetCore.Diagnostics.Abstractions/IExceptionHandlerFeature.cs.
The routing middleware adds route data to the current http context via a request feature - https://github.com/aspnet/Routing/blob/dev/src/Microsoft.AspNetCore.Routing.Abstractions/IRoutingFeature.cs
Generally it's a way to flow per request behavior and state from the server, through middleware, to the application.
I need to send a asynchronous message to client from my CXF (JAX WS) webservice layer...
How client would be capable of receiving it?What steps need to be taken care to achieve this?Is there a sample tutorial available?
You have two options to achieve asynchronous calls from client with CXF.
You can poll the service for response
You can define a callback which will be executed when the server's job is done
Each solution has pros and cons, so choose according to your needs.
The polling gives you a Response object and you can test if the call is complete on it by response.isDone(). (if not, wait some time, then send another request)
The callback gives you a Future object which wraps the call, you can define an AsyncHandler for instance when you call the service to define what will be run when the process is finished.
From the server side, you should take a look at WS-Addressing (to define a replyTo endpoint for callback if needed) and WS-POLICY: http://cxf.apache.org/docs/ws-addressing.html
Note that if you need to use callbacks (it seems so), you will have to define a CXF client on the client side to enable WS-addressing (on the cxf bus).
I'm looking for an example showing how can I configure my CXF project, so that I can call a service method asynchronously; meaning my invocation in the client side doesn't block for the response and when the response is ready the logic will be done. I'm very thankful if somebody can help me
Best
The simplest way is to use #Oneway annotation on the server side. CXF will handle the request on the server side in a separate thread, so the client won't be blocked and will return immediately after receiving 200 response code and empty response body.
Of course in this case you cannot receive any response (by definition of request-only SOAP operation), which is not an option for you. Unfortunately you're need to implement this by hand using thread pool and future tasks. Fortunately this is very simple since Java 5, start by studying ExecutorService API.
Is it required to use a RESTful
service to be able to make a ajax
call to a wcf service (for example: by using
WebInvoke attribute on Operation
contracts)
Once a service is made RESTful by adding a webHttp binding on the service host, can the host have other endpoints as well? (wsHttp or netTcp)
Is it required that the aspNetCompatibilityEnabled be set to true for a service that has webHttp binding (and can this setting coexist for other endpoints)
I understand I can use both JQuery and ScriptManager for making WCF calls on the client. Why should I use one over the other?
Answers
No.
AJAX is typically used for sending simple HTTP GET ("REST") requests. It doesn't have to be so. You could also format a payload using a SOAP envelope, and POST it to the endpoint. In that case the WCF service would have to be wsHttp or basicHttpBinding, at least. Here's an example of using VBScript to create and send a SOAP request, but you could do the same in Javascript. You can't use the more advanced SOAP extensions, like WS-Security, XML DigSig, and so on. Well, you could but it would be impractical. For example, I don't know of any XML canonicalization library in Javascript, which is essential for doing WS-Security or digital signatures. There are 17 similar obstacles. Result: you can't use the more advanced SOAP extensions when calling from Javascript.
.
If you use jQuery ajax, you'll need to use the beforeSend callback on the ajax request to set the SOAPAction header.
.
Having said that, it's a lot easier to process json in a Javascript program, than it is to walk the DOM of an XML document. In other words, you're better off using JSON/REST when connecting from Javascript to WCF, instead of SOAP. Sometimes it's not an option, I guess.
Yes
A WCF service can have multiple endpoints and they can listen on the same or different transports such as HTTP, net.tcp, net.pipe, or net.msmq.
No. aspNetCompatibilityEnabled just enables some ASMX-like features on the server. It affects how the service is designed, and it is independent of the message signature. It does preclude the use of non-HTTP protocols. For more on this, see Wenlong Dong's article.
as for which framework to use on the client - which is easier? I don't have experience with ScriptManager, but the decision criteria is pretty simple. jQuery works just fine, and is appropriate if you already use jQuery. If you don't have or want jQuery, you can use XmlHttpRequest to send SOAP or REST requests. If those are somehow inappropriate, use something else.