Is WF adequated to build an OLTP middleware tier?

We are evaluating Workflow Foundation to build our middleware solution which is a multi-channel banking system (Branches, ATMS, Internet, Phone). Basically, this tier exposes services to the channels. Most of the services are synchronous, but we also have asynchronous services. We also have services that are multi-step, which means we pretend to use the persistence functionality of WF.

We decided to evaluate WF because most of our services have to follow a sequence of activities depending of the type of the service (monetary operation, account statements, etc.), and then the service has specific activities wich implement the business logic of the operation. We are testing this kind of approach using master child workflows (a kind of InvokeWorkflow activity in which you can specify at runtime the type of the workflow) and adptative workflows (using dynamic updates). Basically, we want to put the transversal aspects in the master workflow, wich lets the programmer focus in the business logic of the service (implementing the child workflow). This middleware has agressives SLAs in terms of performance: as an example, an account statement must respond below 1 second.

Our main concern is to understand if WF is adequated to this kind os system in terms of performance Obviously we wknow that making worlflows by hand (native calls to methods) is faster than using the workflow runtime. This is not the question. We believe that using WF is value added to our team (programmers, business analysts, testers). But we have affraid of the performance issue.

By the way, we already decided that we will not use BizTalk because most of our concerns are not integration issues with external systems. Basically we expose Web Services to Channels and we only comunicate with our mainframe gateway with web services. All the other logic is considered internal of our system (ammount validation limits, security validation, business rules, accounts management etc). However, our mind is focused on the BizTalk approach, ie, we receive a message, start or load a workflow based on the type of the message, pass the message to the workflow, the workflow begins the execution processing the message, calling internal methods, and gives a response (maybe we freeze the workflow to execute later).

We know this is a though question, but we need some guidelines here to not being catch in a performance nightmare.

Other opinions about this architecture are also very welcome ;-)

Thanks in advance

Answer this question

Is WF adequated to build an OLTP middleware tier?

Maor
Hi BFC,

We went down this path a few months ago and we came up with a BTS/WF solution.

BTS we positioned (and apart from being partial to BTS) as being a 'Manager' (or overseerer of all of the workflow requests etc)
So BTS in our implementation provides things like:
1. End-To-End Tracking + Business Actvitiy Monitoring to allow no technical users the ability to receive alerts when certain data passes through workflows.
2. Provide the needed fault tolerance and manager environment
3. Look after the 'Parent/Child' Workflow requirements with 'Parent/Child Orchestrations'
4. Implementation of System Global rules - e.g. you need to be the current owner of the 'workflow document' to perform any action.
5. To satisfy Auditing requirements around every request
6. Using Content Based Routing to locate the appropriate BTS pieces to drive the workflow - so there's no 'hard coded' paths through BTS.
7. Very good at handling Sync + Async mixtures of message processing. e.g. Process the workflow request, but need to send 20 emails as well.
8. WF is in Beta (was in Beta 1 when we started) and we wanted to limit the amount of Risk within this project - seeing that we're getting it out the door in the next month.
9. The Business Users can create a WF + external rules. Place them in a 'special' folder and the WF is used (with rules) at the very next request (we compile on the fly)
We liked the prospect of WF:
1. Fantastic at graphically describing Workflow and their states (we use alot of Metadata from the Workflow)
2. Easy for non-technical users to drag a bunch of shapes on to make their workflow.
3. Creation of flexible rules pertaining just to the workflow and what happens.
4. Customisation in the OOTB Activities allowed.
5. Easy deployment model
We exposed the WF as several WS's in a farm environment - so to BTS it's just another WS to call.

As most of our requests are Sync back to the user, at this point we're getting 1.5-4 secs turn around times on our Virtual Server Dev + Staging Servers.

HTH,

Cheers,

Mick.

p.s. We also have SPS integration (v2 at this stage) which is also handled from BTS.
GaetanoDiGregorio

Hello BFC,

We will have performance data published when Windows Workflow Foundation is released - but not before. You are recommended to test the performance of our Beta 2 which is available now and decide if that performance is sufficient for your purposes.

Also, I would not recommend creating all workflows that are executed from your system as multi tier workflows. Having a parent - child relationship for all workflows will impair performance and you will have to write a lot of code just to communicate between these workflows. You would be much better off to code custom activities with the "transversal" aspects or embed these parts of your application into runtime services. This will allow your regular programmers to focus on the business logic created in workflows by designing activities.

Regards,
Paul
Is WF adequated to build an OLTP middleware tier?

Answer this question