Web Service & Actor Framework

[Eldon]

I am integrating the Web Service and the Actor Framework on a cRIO. When the Web Service is started, it launches the root level of the Actor Framework. My philosophical problem is that web services needs to be able to return information that the Actor Framework possesses. This means needing to call the framework with a message and waiting for a response. I agree that it is a bad idea to send a message and wait for a response. I have come up with two options for a solution. The first is to pass a queue created, by the web service, to the framework that is monitored by the web service. This way if the framework takes to long to respond, an error message can be passed back by web service. The second is to move the needed information from the framework to the web service or making it a global. The draw back here is that it loses some of the methodology of encapsulation.

Since I have limited experience with the Actor Framework, I am open to suggestions before I spend much more time programming this aspect of the code.

Thanks,

Eldon

[cirrusio]

Hey Eldon,

I have a real-time system that uses web services also, but I am not fully following you post.  Why does your service need to wait?  If you are looking for regular data, I might recommend storing that data in a DVR that is written to in the main application.  When you service an http request that needs all or some portion of that data, you simply retrieve it from the stored DVR.  No waiting required. 

I recommend a DVR because you can make this accessible at application launch and therefore don't have something dangling out in the global scope.  And, this is what I have used with considerable success.  If you absolutely must communicate through the actor message queues, then simply request a return message using (Reply Message:Send Message and Wait for Response - returns a Reply Message object, I believe).

Cheers, Matt

[lukepike]

I have done a couple of applications using the Actor Framework with a Web Service. I think the method that most aligns with the Actor Framework ideals is the following:

Create a sub Actor that is launched by the root Actor. The root Actor should forward any information the web service needs to display in a message to the sub Actor. The sub Actor then puts the information in one or more functional globals that the web service can access. The functional globals act as the API that the Actor Framework uses to interact with it, much like messages are the API used to interact with Actors.

If the web service needs to send a message to an Actor, abstract messages (as described in this thread) can be used or the sub Actor's message queue can be shared with the web service and it can send messages directly. The first method is more portable and probably more correct, while the second is easier to setup.

Edit: I noticed after sending my response that you are targeting a cRIO, in which case functional globals can be replaced with a different communication scheme if necessary.

[Eldon]

Matt,

The information that is needed is in a class structure that is owned by the root Actor. The reason I have not used the Send Message and Wait for Response is that it is frowned upon.

Forgive my ignorance, but I am not familiar with your acronym "DVR".

Thanks,
Eldon

Message was edited by: Eldon

DVR -> Data Value Reference. I am old school and just call these reference pointers.

[MattP]

Frankly, I'd claim that the web service use case is one of the only reasons why the Send Message and Wait for Response method exists.  It implements essentially exactly what you propose as one of your options (create a queue, send the reply queue along with the request, wait until a specified timeout for a reply message on that queue).  Why reinvent the wheel?

I like to use this pattern (whether AF or not) when I have a cRIO that acts as a command handler controlled by a remote master. In these cases, my messages to the cRIO from the master system are action-oriented as opposed to data-oriented.  Essentially a remote procedure call system rather than a SCADA system.

For example:

A command like  MoveToPosition (x, y) should not return a response until the system is done moving, and it should tell me whether the system moved successfully or if something went wrong.

[cirrusio]

Luke,

Why do you add a subactor? Seems that if all the subactor is intended to do is to serve as a controller that communicates between the root actor and the subactor, you are adding just another layer that doesn't necessarily bring anything to the table.  Is the subactor doing some other actions that would be better suited to that actor rather than the root?  Why not place the functional global in the root actor?  The addition of the extra layer unfortunately entails another set of messages that would not be necessary if the web service was associated with the root.  I would suggest not doing this unless the subactor serves some purpose other than to communicate with the web service.

Eldon - DVR stands for data value reference; it's a reference to a memory space.  And why is Send Message and Wait for Response "frowned upon"?  I have been using the AF since inception and have yet really had to use it, but if it solves your problem I see no reason not to use it. 

I think sometimes we get too hung up on the "right way" to do things and forget that there are multiple approaches which have they're pros and cons.  It is a good thing to think about these things before starting, but it is best not to be paralyzed looking for the best (only?) solution to a particular problem.  Truth be told, best is likely to evolve with the development of your project and the skills you develop. 

Just my two pennies.

Matt

[lukepike]

Matt,

In my application, I didn't have the sub actor, the web service used a functional global directly that was updated by the root actor. The sub actor was something I thought could be helpful, for instance you could swap it out for a different implementation, but you're probably right that it adds more unecessary abstration, something that I struggle a bit with sometimes.

[cirrusio]

This is an interesting architecture issue.  I feel that if you are using web services, the web service should not be depending on information that is not initiated via an http request.  That is, if you want to move the controller, send the command using http GET.  If you need to know the current position, the view portion of the application should be polling at regular intervals for a data packet that contains that current position.  Ultimately, the two requests are independent of each other.  I don't believe that Eldon's intent is to adjust the http status code response based on the device response; so ultimately all  the requester should care about is 1) whether the service is alive and 2) no error was thrown when the request was handled and forwarded.  The state of the component that ultimately handles the request (i.e. the underlying model) should be maintained by the model itself and be part of the data stream that is returned to the controller in charge of aggregating system information.   

[cirrusio]

Luke,

I think that you have given a good reason to have it present.  The abstraction allows you to just swap actors if you want to change the communication method.  Fair enough.

Matt

[cirrusio]

Ya...sure.  But you could also call a shift register a pointer also.  Or a global variable is a pointer.