locked
A customer's question I could use help with RRS feed

  • Question

  •  

    I have a customer that posed these two questions that I could use some help on:

     

    1. I need a more in depth description on how the Workflow runtime works in conjunction with the SpeechServer. I am trying to understand more fully sessions and maintaining session state as well as application state. I need to know how best to take care of that.  Managed code applications have aspects of a web application, but its as though Speech Server (the client) has a special “browser” that runs a modified version of a workflow runtime.  I am just trying to understand this better.

     

    1. I would like to know better how the compilation process works. It appears as though speech applications go through both a compilation process as well as process that “Runs” the speech application for design time.  In a regular workflow application you are able to dynamically add and remove activities. That same process does work in a speech workflow because of what appears to be a conflict in the way the design time environment works.
    Tuesday, November 13, 2007 2:02 PM

All replies

  • hi Russ,

     

    1) I'm not sure I fully understand what you are trying to do or the problems you are having. Managed-code MSS 2007 applications (whether or not they are workflow-based) have a single instance of the application that is instantiated for each inbound or outbound call. That instance stays in memory and active until the call ends and the application calls ApplicationHost.OnCompleted (this is done automatically by the workflow code when the workflow completes.) Thus for a given call the same IApplicationHost and ITelephonySession object is used for the lifetime of the session.

     

    The connection to the workflow runtime is fairly loose: the first time you create/run a speech workflow, we automatically create the WorkflowRuntime. For each workflow-based call, the autogenerated code in your project (if you leave it untouched) will create an instance of your derived SpeechSequentialWorkflowActivity, passing in the appropriate IApplicationHost (thus tying together a particular workflow instance with the TelephonySession.)

     

    Managed code applications are hosted inside of IIS/ASP.Net, but they really are not web applications. In other words, they are activated via HTTP requests, but from that point on they are merely objects residing inside the ASP.Net process, communicating with the outside world primarily via SIP and RTP. You do have access to the ASP.Net Session and Application objects, and you might find some use for them, but by and large they won't really help you.

     

    2) Managed applications needs to be compiled before deployment. Your application must implement IHostedSpeechApplication, and that is the entry point we use when first calling into your code. In addition, if you are using workflow, you must derive from SpeechSequentialWorkflowActivity. The autogen code from the New Project wizard shows how (in the IHostedSpeechApplication.Start method) the workflow is invoked. At design time some of the workflow code is executed, but this is true in the standard workflow case, too. Your workflow classes are instantiated so that they can render themselves on the designer and so that validators can be executed.

     

    It is correct that speech workflows do not support dynamic update. If I recall correctly, that doesn't actually have anything to do with compilation or design-time issues; while it would in theory be possible for us to support dynamic update, it would have been complicated. The speech use of workflow is largely, but not completely, overlapping with the "vanilla" workflow. We added some additional functionality (e.g., the GoToActivity), but we also chose not to suppose certain things (dynamic update, de-/re-hydration of workflows while running, etc.)

     

    I hope this helps,

    Dan

     

    Wednesday, November 14, 2007 12:48 AM