locked
Load XAMLX from database RRS feed

  • Question

  • I've seen a few posts discussing this scenario, but I'm still struggling with what might be the best solution...

    Scenario:

    1. I've a rehosted designer to allow users to create XAMLX
    2. These XAMLX are stored on a database
    3. I now need to be able to expose these XAMLX in IIS to be consumed by clients
    4. Clients will be able to compose the right addresses to reach these XAMLX. Examples: http://server/WFSite/V1/MyService.xamlx; http://server/WFSite/V2/MyService.xamlx; or similar for non-http protocols


    My question is, what is the best solution to load and expose the xamlx services in IIS?

    Possible solutions that I've found so far:

    1. Use a ServiceHostFactory with a ServiceHost to load the XAMLX from the database
         Option 1:
              a. Requires an .svc file for each .xaml file stored in database. The .svc file is needed to specify the ServiceHostFactory for each XAMLX.
              b. Clients would reference the XAMLX by referencing the .svc endpoint address
              Good: Is as possible solution
              Bad: Requires a sync between the XAMLX created on the database and the .svc files created on the file system. 
         Option 2:
              a. Change the web.config file to add to the serviceHostingEnvironment\serviceActivations section references to relativeAddress, service, factory. The same as Option 1, but without the need of the .svc file
              b. Clients would reference the XAMLX by referencing the .svc endpoint address
              Good: Is also a possible solution, but probably worst than Option 1. Doesn't need the .svc files on the file system.
              Bad: Requires a sync between the XAMLX created on the database and the required changes on the web.config.

    2. Try what others have done with the implementation of a custom VirtualPathProvider
         a. I haven't tried this one yet but from the similar posts on this and WCF foruns it might look as a possible solution
         b. Requires registration of the VirtualPathProvider in global.asax or in a static method called AppInitialize() in any static class placed in the App_Code folder
         Question: Will this work for non-http protocols?

    3. I also made some investigation with WCF Service Discovery, but I was unable to find a solution here.

    Does anyone have a similar problem? Found a good solution? For the moment the best solution I have is the first one using Option 1, but I still don't like it, so I'm looking here for a better way of doing this. Any ideas?

    Thanks!

    • Edited by Nelson Morais Wednesday, October 6, 2010 5:10 PM Minor update at 2.b sentence
    Wednesday, October 6, 2010 1:09 AM

Answers

  • Hi, Nelson

    It is not easy. I have not done such a thing before. but after some thinking. one option comes to my mind.
    1. Use XAML workflow instead of XAMLX.
    2. Use customized bookmark activity instead of Receive Activity.
    3. Use WorkflowApplication.

    Then, you have to create WCF contracts for the workflows stored in the database. when a request comes. the class implement the contract create a WorkflowApplication base on the xaml workflow definition. then workflow instance will be persisted when it is idled. the request should at least contain two parameter: 1. workflow name 2. correlation content.  when the request comes , you need to determine the workflow definition according to the workflow name. And by the correlation content, the server side know which instance to resume , if there are no persisted workflow instance in the instance store, you create a new workflow instance.

    In a high level. you expose WCF svc services to the client. and xaml workflow working in the behind.  XAMLX workflow  serviceis kind designed for running in IIS7/Appfabric directly and seems not very easy to be used stored in database.

    Hope this helps
    Regards


    This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft Online Community Support. My Blog:http://xhinker.com "Microsoft Windows Workflow Foundation 4.0 Cookbook"
    • Marked as answer by Andrew_Zhu Wednesday, October 13, 2010 6:34 AM
    Friday, October 8, 2010 8:30 AM
  • Hi Nelson,

    I agree with Andrew, creating a dynamic workflow is not easy task for generic workflow service solution hosted on the IIS/WAS/AppFabric based on the metadata stored in the database. This Pull Model scenario requires solutions for handling:

    -          Versioning problem

    -          Recycling a host process

    -          Compatibility with AppFabric    

    -          Loading custom assemblies and their versions

    -          Loading other resources required by runtime projector (for instance: config, xslt, …)

    -          Long and short running processes

    -          Business isolation

    -          Hosting isolation

    -          Reconfiguration on the fly

    -          Pub/Sub (broadcasting) agent for refreshing metadata from Repository

    -          Refreshing workflows on the fly without any glitches

    -          Tooling support for logical model stored in the Repository

    Well, the above requirements can be eliminated by the business requirements for model stored in the Repository. For instance, Repository will store only Activities for business mediators invoked by parent workflow service in synch manner passing the business arguments a returning an output arguments.

    In other words, the business process can be decoupled into “fixed” part and small generic business mediators (Activities) stored in the Repository for their customizing on the fly. From the architecturing point of the view, we can see a pattern for Distributed Workflow, when the workflow is decoupled into small workflows in the transparently manner without knowing location of their runtime projecting such as in the same domain (pulled from the storage), in the specific domain or unknown domain (via services).

    In conclusion my comment, your simple solution for dynamic workflows will limit some production features described above and it should be considered in prior.

    Thanks

    Roman


    Roman Kiss, MVP Connected System Developer
    • Marked as answer by Andrew_Zhu Wednesday, October 13, 2010 6:34 AM
    Friday, October 8, 2010 8:36 PM

All replies

  •  

    Hi Nelson,

    Basically, there are two kinds of scenario for this solutions such as:

    1. Pushing metadata from Repository

     

    In this case, like it is shown in the above picture, the metadata is pushed (deployed) to the local storage such as file system and then resources are projected in the hosted process. This is a standard scenario supported by the IIS/WAS/AppFabric Technologies.

    2. Pulling metadata from Repository

    In this case, the hosting process will bootstrap metadata from the Repository for its runtime projecting. This scenario requires a custom hosting support, recycling a host process, etc. This is a custom scenario which can have a problem deploying on the Windows Azure AppFabric.

    More details about these scenarios can be found in my articles: Manageable Services and Contract Model for Manageable Services.

    Back, to your question, which option is the best solution for your scenario, I can recommend you using a Push Model, where your Tools will create a logical centralized  model in the Repository and then based on the deployment model will be deployed to the targets (physical decentralized).

    Also, I recommend for this scenario using a Router Service for virtualization physical endpoints to/from your model. The routing table should be a part of the metadata stored in the Repository for centralized logical connectivity between the clients, 3rd party services, etc. and your model. Using the Router in your scenario will isolate and virtualize physical connectivity to your services where they can be physical located anywhere. More details about this routing concept see in my article Routing Manager for WCF4

    One more note, any changes in the Repository (model) will require to re-deploy model to the targets. Therefore, I recommend to isolate application model during the design time into two parts such as part for deployment time and runtime. The first part is using a Push Model to deploy metadata for its runtime projecting and the second one is for Pulling metadata during the runtime processing. As you can see, this is a hybrid solution. More details about this implementation can be found in my recently article Enterprise Variable for WF4.

     

    Thanks

    Roman

     


    Roman Kiss, MVP Connected System Developer
    Wednesday, October 6, 2010 11:19 PM
  • Hello Roman,

    In first place, let me say that I've been following some of your great articles regarding WF posted on TheCodeProject for a while now, and it's an honour to have you replying to my post.

    I've read the articles you've mentioned, but due to current project constraints there's no way I could follow the patters / solutions you've described in these articles.

    For the moment what I need is a much, much simpler solution that allows XAMLX files to be stored on a database, but still be exposed as services in IIS/WAS.

    Thank you.


    Nelson Morais nelsonmorais@yahoo.com
    Thursday, October 7, 2010 5:25 PM
  • Hi, Nelson

    It is not easy. I have not done such a thing before. but after some thinking. one option comes to my mind.
    1. Use XAML workflow instead of XAMLX.
    2. Use customized bookmark activity instead of Receive Activity.
    3. Use WorkflowApplication.

    Then, you have to create WCF contracts for the workflows stored in the database. when a request comes. the class implement the contract create a WorkflowApplication base on the xaml workflow definition. then workflow instance will be persisted when it is idled. the request should at least contain two parameter: 1. workflow name 2. correlation content.  when the request comes , you need to determine the workflow definition according to the workflow name. And by the correlation content, the server side know which instance to resume , if there are no persisted workflow instance in the instance store, you create a new workflow instance.

    In a high level. you expose WCF svc services to the client. and xaml workflow working in the behind.  XAMLX workflow  serviceis kind designed for running in IIS7/Appfabric directly and seems not very easy to be used stored in database.

    Hope this helps
    Regards


    This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft Online Community Support. My Blog:http://xhinker.com "Microsoft Windows Workflow Foundation 4.0 Cookbook"
    • Marked as answer by Andrew_Zhu Wednesday, October 13, 2010 6:34 AM
    Friday, October 8, 2010 8:30 AM
  • Hi Nelson,

    I agree with Andrew, creating a dynamic workflow is not easy task for generic workflow service solution hosted on the IIS/WAS/AppFabric based on the metadata stored in the database. This Pull Model scenario requires solutions for handling:

    -          Versioning problem

    -          Recycling a host process

    -          Compatibility with AppFabric    

    -          Loading custom assemblies and their versions

    -          Loading other resources required by runtime projector (for instance: config, xslt, …)

    -          Long and short running processes

    -          Business isolation

    -          Hosting isolation

    -          Reconfiguration on the fly

    -          Pub/Sub (broadcasting) agent for refreshing metadata from Repository

    -          Refreshing workflows on the fly without any glitches

    -          Tooling support for logical model stored in the Repository

    Well, the above requirements can be eliminated by the business requirements for model stored in the Repository. For instance, Repository will store only Activities for business mediators invoked by parent workflow service in synch manner passing the business arguments a returning an output arguments.

    In other words, the business process can be decoupled into “fixed” part and small generic business mediators (Activities) stored in the Repository for their customizing on the fly. From the architecturing point of the view, we can see a pattern for Distributed Workflow, when the workflow is decoupled into small workflows in the transparently manner without knowing location of their runtime projecting such as in the same domain (pulled from the storage), in the specific domain or unknown domain (via services).

    In conclusion my comment, your simple solution for dynamic workflows will limit some production features described above and it should be considered in prior.

    Thanks

    Roman


    Roman Kiss, MVP Connected System Developer
    • Marked as answer by Andrew_Zhu Wednesday, October 13, 2010 6:34 AM
    Friday, October 8, 2010 8:36 PM
  • I recommend the VirtualPathProvider solution.

    How To Load WF4 Workflow Services from a Database with IIS/AppFabric

    Windows Workflow Foundation (WF4) - Workflow Service Repository Example


    Sr. Program Manager, AppFabric Development Platform (WF/WCF) http://blogs.msdn.com/rjacobs http://www.twitter.com/ronljacobs
    Wednesday, June 15, 2011 10:05 PM
  • Hi Ron,

    Thanks for your post.

    The research I've done when this post was created (9 months ago :D) I didn't find a way to have this solution working with non-HTTP protocols, and this was my question at the time:

    ...

    2. Try what others have done with the implementation of a custom VirtualPathProvider
    a. I haven't tried this one yet but from the similar posts on this and WCF foruns it might look as a possible solution
    b. Requires registration of the VirtualPathProvider in global.asax or in a static method called AppInitialize() in any static class placed in the App_Code folder
        

    Question: Will this work for non-http protocols?

    ...

    Have you check if this solution also works for non-HTTP protocols, like net.tcp and net.pipe?

    Blog post about this item on http://nmorais.wordpress.com/2011/06/16/load-xamlx-from-database/

    Thanks,


    Nelson Morais nelsonmorais@yahoo.com
    • Edited by Nelson Morais Thursday, June 16, 2011 1:54 AM Blog post link added
    Thursday, June 16, 2011 1:20 AM
  • Think of a XAMLX file that exposes a unique service contract to the clients. On the other hand we have many XAML files to implement workflows that contain messaging activities that expose the same contract as the main XAMLX activity. I think there is no reason to use WorkflowServiceHost to load XAML activities dynamically into XAMLX, but unfortunately the WorkflowInvoker.Invoke method is not working in this case. Any ideas?
    Saturday, November 3, 2012 7:22 PM