Communicating between Flex and .NET

[Former Community Member]

I need to be able to setup communication between Flex3 and
.NET. I have been reading about the following:



- HTTP Services

- Web Services

- Remoting



Based on what I have read I believe webServices will do what
I need for my application. BUT.... I cannot find any information
stating I can call the Flex client from .net as a request.
Everything seems to be ( request -> response ) from Flex to
.net. Can the ( request -> response ) cycle work both ways? If
yes, can someone explain how to use an operation defined in SOAP to
call actionscript. I think I am missing something here.



Here is what I want to be able to do.



- Flex app loads up and is running.

- An .net based application changes state.

- .net sends the information to the flex client

- flex could send a response back to .net.



So the concept is Flex Web Services backwards. Request's come
from .net and responses go to flex.



Alternate Option:

Can I make a request from Flex to .net and then send a
response later when the .net application changes state???

- Are response's sent with a return statement. Or can I
dispatchEvent's from .net?



Thanks for you help.

Dustin

[Former Community Member]

This may be slightly incorrect...



if your web service's url is:
http://localhost/FlexAsp/Service.asmx,



and your c# webmethod is:

[WebMethod]

public string HelloWorld(string myName)

{ return "hello, " + myName; }



then the following mxml code would call the function:



<mx:Application xmlns:mx="
http://www.adobe.com/2006/mxml"
layout="vertical">

<mx:WebService wsdl="
http://localhost/FlexAsp/Service.aspx?WSDL"
id="service" />

<mx:TextInput id="myTextInput" />

<mx:Text id="myTextOutput"
text="{service.HelloWorld.lastResult}" />

<mx:Button id="btnSend"
click="this.service.HelloWorld.send(this.myTextInput.text)" />

</mx:Application>



Keep in mind that I have not tested any of this code..

[Former Community Member]

Thank you for the response. Not exactly what I am looking
for.



The goal of a web service is to make a (request) from flex
through a web service that flex & actionscript initialize. That
request then hits the web server counterpart (asp, php, etc..) to
be processed.. This is an operation call through the web service.



What I am looking for is the concept ExternalInterface does.



ASP calls flex through a web service setup by Flex. Now the
first thing you will think here is ... How would ASP know that Flex
has a webservice let alone communicate to it? Not sure..I want to
know can it be done and how?



I think the concept of web services is limiting since it is a
2 way communication cycle where the request only come from the web
service initializer, in this case FLEX.



I would like to have a site that uses a flex client for a
small part of the enitre application. I want to be able to use asp
to make updates to other parts of the site which in turn update a
database. I want FLEX to know this update has occured and when by
brocasting a call through a webservice. The reason I am content on
web services for this .. is my flex app will use the service to
update the data when states change in the flex app.



It would suck to have to use ExternalInterface so ASP can
make that one request to flex and then every other (request ->
response) go through the web service.



Why are Web Services one way??????????????????????????? I was
under the impression it is this great feature, but never thought it
would be limiting in this way.



Dustin

[nmj]

Dustin,

The nature of a web service using the HTTP protocol is that
it is totally client-side initiated, so your web server does not
retain a live connection to the client in order to signal the
changes. if you really want to use a web service, you will probably
need to set up an instance of a timer class (
http://livedocs.adobe.com/flex/2/langref/flash/utils/Timer.html)
in your Flex client to poll the server for a "last changed
date/time" and when the server replies with a new value, then you
should have the client pull the new data and update your client.
The down side to this approach is that the clients will only get
the update as quickly as their cycle time permits.

I believe you have an option to use remoteObject instead
which could keep an open connection between the client and server,
but I have not tried it...yet. Both of these will have scalability
issues if you have many users connected at the same time, but the
architecture necessary to handle each approach will be different,
so you should decide up front.