I am consuming a a WCF web service from APS.NET 1.1 and I read in everywhere that we need to
1 : Add XmlSerializerFormat attribute to the ServiceContract we want to consume.
2 : Use basicHttpBinding as Endpoint setting.
Why so?
-> Is it possible to set the POINT 1 condition someway in configuration file ?
-> When basicHttpBinding's default is XML serialization. Why do we need to explicitly declare the service contract as XmlSerializerFormat
?
Out of the box, I do not think WCF provides a way to override default serializer (i.e. DataContractSerializer). You however can create custom Service\Operation Behavior, define configuration element for custom Operation Behavior and use this to override serializer.
Default serializer of BasicHttpBinding is DataContractSerializer, NOT XmlSerializer. Both serializers work differently (although produce xml output). You can checkout the difference between behavior of these two serializers.
Related
To enable OData after installing the Microsoft ASP.NET Web API 2.2 package, the only thing to do is add the attribute EnableQuery and return IQueryable.
If the attribute EnableQuery is only metadata, what change in the framework?
I mean, when an request arrive the framework matches the url with the Route Table and then create the controller to manage the request. What does change with OData?
EnableQueryAttribute derives from ActionFilterAttribute, which means it can affect the result of an action via its OnActionExecuted method (called internally by Web API). Take a look at the source code to see what EnableQuery is really doing.
How can I use ServiceBehaviorAttribute in my Web API 2 project to create & recycle instance context object on every request? I tried to set it traditional way by configuring in web.config but didn't work. I think I may need to set custom attribute so any suggestion/thoughts are appreciated!
[ServiceBehaviorAttribute(InstanceContextMode = InstanceContextMode.PerCall)]
I am new to Web API so not having much exposure on it.
The ServiceBehaviorAttribute is in the System.ServiceModel namespace and is used exclusively for WCF not for Web API. The following link seems to address your issue: Programmatically set InstanceContextMode
I have a problem when calling web Services in ASP.net MVC , I do the following
add the web service by add service reference to solution, and I include the service.cs file to the solution also, but when I try to create object in home controller , I have the following error
Could not find default endpoint element that references contract 'Service' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.
can any one help me please
thanks
There's a couple things going on here. First, you're using SVCUTIL to generate a proxy and configuration settings for a non-WCF service - .asmx is legacy. I was able to generate a proxy and config settings, but to overcome the error you got you need to call one of the overloaded versions of WeatherHttpClient.
I'm not 100% sure, but this is what I think based on what I observed.
The reason is because there are two endpoints defined in the configuration file (one for SOAP 1.1 and one for SOAP 1.2), and since both endpoints are named there is no default endpoint to choose from.
When I used var x = new WeatherHttpClient(new BasicHttpBinding("WeatherSoap"), new EndpointAddress("http://wsf.cdyne.com/WeatherWS/Weather.asmx")); I was able to create the proxy just fine.
However, when I called GetCityForecastByZip I got the following error:
Server did not recognize the value of HTTP Header SOAPAction: http://ws.cdyne.com/WeatherWS/WeatherHttpGet/GetCityForecastByZIPRequest.
So then I used WSDL.exe to generate the proxy a la .ASMX style. I included that in my project, and the following code returned a result (after including a reference to System.Web.Services - I was using a console app):
var x = new Weather();
ForecastReturn result = x.GetCityForecastByZip("91504");`
I would suggest for simplicity using WSDL.exe to generate the proxy for your service, as it seems to be simpler.
I will also add that I've done very little MVC, but I don't think this is an MVC issue. I hope this helps you.
In Flex 3, introspecting a web service resulted in a constructor that allowed the location of the web service to change at runtime. It appears that the Web Service introspection tool now only allows the single WSDL URI that was specified in the WS Wizard. It this the case or am I just missing something?
Flex 3 introspected services would create a service class with the following constructor signatures:
private var service:MyWebService;
service= new MyWebService(null, wsdlLocation); // With parameters
or you could use:
service = new MyWebService(); //with no parameters
In Flex 4, it appears that you can only use:
service = new MyWebService();
So if you don't know the web server location until runtime, am I going to need to manually override the instrospected/generated _super_MyWebService.as class in order to get back the ability to point to different servers at runtime?
Anyone know why this has changed, or what the "new" way the Flash Builder 4 web service introspection tool uses for dynamic servers?
I found a solution to this question on the Adobe Forums.
The solution is to set the wsdl property once your service is created:
var service:MyWebService = new MyWebService();
service.wsdl = "location to the wsdl";
It should be noted that using the Flash Builder 4 web service introspection tool will automatically populate the wsdl location in the superclass. According to the post on Adobe Forums, it is necessary to remove the wsdl location in the superclass or the value will not get reset.
I am running blazeds on the server side. I would like to filter http requests using an http header. My goal is to send extra parameters to the server without changing the signatures of my blazeds services.
On the client side, I am using Flex RemoteObject methods.
With Flex WebService components, it is possible to set an http header using the property httpHeaders. I have not found anything similar on the RemoteObject class...
I couldnt modify http request from flex, instead I can add custom headers to the mx.messaging.messages.IMessage that RemoteObject sends to the server and there, extending flex.messaging.services.remoting.adapters.JavaAdapter (used for accessing Spring beans), it's posible to read the header parameters and put them into the HTTPRequest.
In the flex part, I had to extend mx.rpc.AsyncRequest:
declares a new property "header" and overwrites invoke method that checks if there is a not null value for set the msg.headers.
and mx.rpc.remoting.mxml.RemoteObject:
the constructor creates a new instance of our custom AsyncRequest and overwrite old AsyncRequest and it defines a setHeaders method that set the argument to the custom AsyncRequest.
com.asfusion.mate.actions.builders.RemoteObjectInvoker (extra :P):
this one reads the param declared in the Mate's map RemoteObjectInvoker and puts in the RemoteObject header.
I hope it will be understandable (with my apache english xDDD)
Bye. Agur!
This worked for me using BlazeDS and Spring-Flex 1.5.2
Flex:
use namespace mx_internal;
var service:RemoteObject = new RemoteObject(destination);
var operation:Operation = service[functionName];
operation.asyncRequest.defaultHeaders = {company:'company'};
var token:AsyncToken = operation.send();
Java Spring-Flex:
public class FlexJavaCustomAdapter extends JavaAdapter{
#Override
public Object invoke(Message message) {
String locale = (String) message.getHeader("com.foo.locale");
return super.invoke(message);
}
}
dispatcher-servlet.xml
<bean id="customAdapter" class="org.springframework.flex.core.ManageableComponentFactoryBean">
<constructor-arg value="com.codefish.model.flex.FlexJavaCustomAdapter"/>
</bean>
<flex:message-broker id="_messageBroker" services-config-path="classpath*:/com/codefish/resources/spring/services-config.xml" >
<flex:remoting-service default-adapter-id="customAdapter"
default-channels="my-amf, my-secure-amf" />
</flex:message-broker>
</bean>
RemoteObject uses AMF as the data channel, and is managed in a completely different way than HttpService or WebService (which use Http).
What you can do, is call setCredentials(username,password) and then capture this on the server side using the FlexLoginCommand (either the standard one for your container, or derive your own).
Lookup setCredentials and how you should handle this on both sides (client and server).
I have similar problem, and I afraid there is no simple way to set HTTP header when using AMF. But I've designed following solution.
Flex uses HTTP to transfer AMF, but invokes it through browser interfaces, this allows you to set cookie. Just in document containing application invoke following JavaScript
document.cookie="clientVersion=1.0;expires=2100-01-01;path=/";
Browser should transfer it to server, and you can filter (problem will be if the user will have cookies turned off).
Much more you can invoke JavaScript functions from Flex (more is here: http://livedocs.adobe.com/flex/3/html/help.html?content=passingarguments_4.html).
You might be trying to re-invent the wheel. Is there a reason you can't use the standard HTTP(s) authentication?
A reason I was thinking too to use http headers was for the server to be able to 'recognize' the flex client in the a context of service versionning.
On the server I can always build an indirection/proxy that would allow the different clients to only use 1 end point and route to the right adapter depending on the client version.
The question is on the client side. How would the server identify the flex client token or 'version'. One way is certainly via authentication. But, assuming there is not authentication involved?
We recently run into the same issue and this is how we added our custom headers without creating a subclass:
var operation:AbstractOperation = _remoteSession.getOperation('myRemoteOperation');
var async:AsyncRequest = operation.mx_internal::asyncRequest;
async.defaultHeaders = {my_header:'my_value'};
The AsyncRequest object is actually accessible via the operation object via the mx_internal namespace.
You can debug the $GLOBALS in PHP to see that.
I think this is in the
$GLOBALS['HTTP_RAW_POST_DATA'];
or you can simple do
file_get_contents('php://input');