Quelle est l'architecture du serveur de workflow?

Question

nous sommes PLANING pour développer un serveur wf avec Microsoft WF4
les exigences est de créer un concepteur d'utilisateur final pour les flux de travail, l'application client de sorte que chaque utilisateur de suivre les tâches

quelle est la meilleure architecture pour ce serveur?

J'apprécie votre aide

Plus de détails:

nous développons un système de gestion des documents, nous avons besoin de créer un système de flux de travail comme Ultimus sûr de ne pas grand comme ça, mais le même concept; serveur wf et designer wf, wf client

1 ainsi que le designer wf se connecter au serveur wf pour gérer les WFS enregistrés comme checkin, caisse, supprimer

2- le client wf, l'utilisateur normal connecter au serveur pour obtenir quelles sont les tâches qu'ils ont comme approuver, rejeter, bla bla

3- le client wf, l'utilisateur Admin va se connecter au serveur pour obtenir quelles sont les tâches et pour surveiller le wfs, obtenir le état de tout flux de travail

Je suis utilisé ultimus auparavant, il suffit d'installer le serveur ultimus sur le serveur et les clients seront Je viens connecter au serveur, ce client peut être Web ou mobile ou de bureau

ce sont les exigences du système

J'ai besoin de connaître l'architecture logicielle

Answer 1

La meilleure architecture dépend de ce que votre non-functional les besoins sont (par exemple: est-ce un outil qui ne sera utilisé en interne ou allez-vous le vendre? Combien d'utilisateurs? Où et comment les utilisateurs pourront-ils accéder au système?), Il y a beaucoup de qualité à laquelle vous devez penser. Le fait que vous ayez affaire à WF4 n'est pas très important - la connexion à un service de serveur principal est assez courante. WF4 pourrait avoir des façons "spéciales" de l'intégrer mais je ne sais pas quelles sont ces spécificités - peut-être sont-elles ce que vous recherchez?

architecture de haut niveau

Rien de fantaisie nécessaire ici, 4 couches principales:

1. Niveau de l'interface utilisateur:. (Vous pourriez avoir plus d'une interface utilisateur, et nous espérons qu'ils peuvent partager le code
2. Business Logic: bien que le serveur MS WF fasse tout le "heavy lifting" aussi loin que le WF va, vous voulez toujours avoir un endroit où vous pouvez mettre une logique commune
3. Couche d'intégration: ce sera b e quelques choses, éventuellement Dependency Injection (DI) ou un Facade au serveur MS WF, de sorte que lorsque MS apporte des modifications, vous n'êtes pas explicitement lié à eux (autant). Vous aurez probablement aussi besoin de votre propre couche d'accès aux données - utilisez cette couche d'intégration pour l'abstraire et l'intégrer aussi, ainsi que tous les autres services que vous souhaitez offrir ou consommer.
4. Référentiels de données et services WF personnalisés: pour stocker vos propres données et s'intégrer profondément avec WF4.

UI - WF Designer

La conception des flux de travail n'est pas trivial, la construction d'une interface utilisateur/système qui permet aux utilisateurs de le faire est encore plus difficile, donc je suppose que vous voulez une technologie d'interface utilisateur permet une interaction riche - peut-être SilverLight est une option? Cela vous permettra de livrer l'application sur Internet si nécessaire (peut-être bien pour les utilisateurs qui se connectent à distance).

D'autres options incluent HTML (pensez HTML5) ou un client lourd: c'est là que l'environnement de vos utilisateurs est important - quel niveau de contrôle avez-vous dessus/quelles contraintes vous sont imposées?

UI - Flux de travail Surveillance

Beaucoup d'options ici, c'est là que vous devez entrer dans le dialogue avec vos utilisateurs et voir ce qu'ils veulent. Vous pouvez offrir plusieurs moyens de surveiller l'exécution des flux de travail:

• Une interface utilisateur «riche» qui permet une surveillance complète (pensez aux administrateurs et aux utilisateurs expérimentés); SilverLight pourrait être à nouveau un concurrent (en supposant que vous l'utilisiez pour le concepteur WF). En supposant que c'est "en lecture seule" vous pourrait être en mesure d'utiliser une approche plus ouverte/low-tech - comme le droit HTML (pas que le HTML est nécessairement low-tech ces jours-ci). Gardez à l'esprit que si vous voulez afficher une représentation graphique d'un workflow, vous allez essentiellement créer une version réduite du concepteur WF. Si les gens veulent juste des informations sommaires vraiment basiques, vous pouvez augmenter les interfaces utilisateur principales avec des widgets plus petits que les utilisateurs peuvent utiliser pour garder un œil sur les WF clés - comme un add-in pour FireFox, un petit moniteur TaskBar, etc.

Logic Busiess (BL)

Cela devrait être simple, mais bien réfléchir à la façon dont vous intégrez avec WF - d'une part vous liant à elle sera directement fournir d'excellentes occasions de livrer rapidement fonctionnalité cool - mais d'autre part, vous serez étroitement couplé à WF: si cela change, vous êtes en difficulté. J'imagine que le BL aura besoin de consommer de l'information provenant de divers endroits - dont certains vous inventeront: ils doivent tous être extraits derrière une interface (DI). Vous pouvez également fournir certains services (pour le remplissage de commandes d'interface utilisateur pilotées par AJAX, la commande de widgets, etc.); mettre autant de logique dans le BL que possible et lui fournir différents canaux via l'interface utilisateur et les couches d'intégration. Je suppose que cela devra être enveloppé comme un service Windows; si vous gardez votre logique de base, vous devez également définir proprement pouvoir réutiliser dans un site Web, WebServices, etc.

couche d'intégration

Cela pourrait être relativement mince, un coup d'oeil à un DI cadres avant de rouler les vôtres; WCF est une option évidente aussi.

données et Référentiels personnalisés WF services

Cette couche tiendra les implémentations concrètes de tous les référentiels de données que vous créez. Il contiendra également tous les composants WF personnalisés que vous créez. Rappelez-vous que ces couches sont logiques dans un premier temps, mais qu'elles se traduisent également en couches physiques la plupart du temps. À un certain moment, vous aurez besoin d'écrire du code qui fonctionne directement contre WF4 - c'est cool, mais vous voulez vous assurer que le code est aussi petit et "jetable" que possible; l'architecture décrite ici devrait permettre cela. Ainsi, lorsque vous développez les composants de code qui s'intègrent profondément avec WF4, gardez-les petits et modulaires - faciles à remplacer, consommez-les via la couche d'intégration; tout ce que vous devez faire est de garder loose-coupling à l'esprit: DI, etc.

Considérations finales

• Une fois que vous avez une idée de l'architecture de haut niveau, un coup d'oeil à travers la documentnation WF4 - ce que vous recherchez des options d'intégration qui correspondent.
• Si vous ne parlez que de workflows simples pour la gestion de documents, vous pouvez adopter une approche dans laquelle les utilisateurs ne conçoivent pas de workflows, mais les configurent simplement; Dans ce cas, vous n'avez pas besoin d'un concepteur WF complexe/intelligent. Parallèlement, vous concevez votre système de sorte que vous puissiez facilement déployer de nouveaux flux de travail pour l'utilisation/la configuration.

Answer 2

Vous pouvez commencer par prendre un bon regard sur le Windows Server AppFabric comme c'est la première version de Microsoft d'une version hôte de service de flux de travail au-dessus de IIS 7.