Skip to content

EasySOA and workflow build process

Jump to bottom Edit New page
fenrhil edited this page Jul 26, 2012 · 20 revisions

Summary

Analysis

Here is a rough description of the workflow "build process" as we see it. We chose the perspective of information flow, as EasySOA's main feature is about documenting. The notation is loosely based on UML. Here is the meaning of each construct in this particular notation:

  • Actors are human users
  • Components are pieces of software performing automated tasks and interacting with users
  • Arrows represent flows of information between these components and actors

As for the vocabulary, here are some quick definitions:

  • Business workflows are "raw" business process models, carrying no technical information. Example: BPMN2 files without engine-specific data.
  • Technical workflows are refined business process models, with technical information (connectors settings, services endpoints). Example: ".workflow" files in Eclipse JWT or BPMN2 files with engine-specific connector settings.
  • Executable workflows are deployable files that provide process definitions to workflows engines. They include a good deal of engine-specific data. Example: Bonita ".bar" files.

We can see a few problems here:

  • Files are exported/imported manually. Where to find a file depends on who last edited this file. Maybe someone forgot to upload it on the shared storage, or gave it the wrong name, and so on. Coupled with versioning problems, this may add a great deal of complexity to the process.
  • Versioning has to be managed manually by architects. SCM systems are overkill for these files (which are mostly either binary or XML-based), and are mostly aimed at technical users.
  • Users have no centralized place for written communication about workflows. Classical solutions for commenting (like adding ".doc" files along with the models) bring up new issues when using them collaboratively.
  • Service connector settings are provided manually by the technical architect. This involves many painstaking copy/paste, and any typo can make the description completely unusable, involving potential runtime errors.

In other words, actors spend some time working on data just to organize it, with mixed results. This is simply a waste of time, since automated tools could do most of the job.

EasySOA as a solution

As we can see, EasySOA becomes the central hub of business process information. At all times, the information about the business/technical workflows is accessible (and up-to-date) in EasySOA, which then provides a full-featured online storage facility.

Improvements

  • Automatic import and export come naturally, since the files are centralized in EasySOA.
    • Whenever a file is saved, it is transfered to EasySOA directly from the editor and is stored along with older versions.
    • Whenever someone needs to import a file, he knows where to find it: on EasySOA. A natural, efficient way of organizing documents shall be provided by the platform.
  • Versioning is made easier thanks to the Nuxeo platform. (See Folder versioning for more information)
  • EasySOA helps in documenting workflows. Files can be commented, organized. (See Final soa model design for more information)
  • Workflow editors can capitalize on EasySOA's services repository to fill service connectors settings automatically. Technical architects only have to choose which service among those documented in EasySOA they want to use.

Additional, non-trivial features could capitalize on these added information in EasySOA (using workflow definitions, or data provided by editors when exporting). Here are some:

  • Automatic business process hierarchy synchronization. Links between processes and sub-processes could be modeled in EasySOA.
  • Automatic service dependency synchronization. Links between processes and services they use could be modeled as well.

Risks/drawbacks

  • Editors modification In order to provide seamless integration with EasySOA, editors have to be modified. This means that:
    • Not every editors can be integrated, for multiple reasons (license, lack of plugin system, cost, ...).
    • Therefore, manual import/export features must be provided alongside heavily integrated features.
  • Network dependency Since EasySOA is probably not running on the same machine as the editor, you must be connected to the same network in order to save a workflow-related file. Thus:
    • This kind of architecture prevents offline editing of diagrams, since nobody wants to work on something they are not sure they are going to be able to save.
    • Even if the online storage feature is kept compatible with offline storage, the resulting system would lose its consistency: it would not promote online storage, resulting in some files beeing stored locally, some others online...

User stories

Actors

  • Bob, business architect
  • Ted, technical architect

User story #1

  • Bob creates a new BP diagram in his favorite editor [1]

  • Before drawing anything, he defines, in the process properties, the "context information" [2]

  • Bob draws diagrams. He saves periodically the file to EasySOA, where clients can review the models later if they wish.

  • When clients are content with the model, Bob saves the last version and closes his editor.

  • Bob informs Ted that he can start working.

  • Ted imports the diagram from EasySOA in his favorite editor [1]. Thus he creates a new, "technical" workflow diagram in EasySOA (TODO: is it mandatory? (e.g. in JWT))

  • While working, Ted periodically saves his diagram to EasySOA.

  • Optionally, Ted completes the "context" [2] with technical information

  • Ted reviews the business architecture

  • Optionally, Ted refactors the diagram to reflect the technical architecture. He can split the process into several subprocesses, each one related to a subsystem.

  • Ted adds web service applications (each one modeling a provided service already known in EasySOA [3]). Each time he adds an application:

    • a wizard appears, listing all available services (in the process context)
    • Ted filters the web services (by name, by including system, ...)
    • Ted selects the service he wants to add
    • A new application appears on the diagram, showing at least some cosmetic information (service name) [4]

  • When he's done, Ted saves one last time

  • Ted exports his model from JWT to an executable format, e.g. Bonita's ".bar" files.

  • Ted closes his editor.

Notes

  1. In our case, we'll start with a simple use case where all users rely on Eclipse JWT
  2. Context information are all information relative to the process, e.g. the system it's related to. The exact information still has to be determined.
  3. Optionally, we could provide facilities to add new services to EasySOA directly from JWT.
  4. The exact information about the services stored in JWT are still to be defined. We can store only their name and an ID that EasySOA could understand, or we can also store more technical information, as WSDL URLs, ...

Features

Here is a list of the added features on which we shall work:

  • Import and export of workflow files from/to EasySOA
    • File saving/loading:Architects shall be able to work on workflow files (business, technical and executable files) stored on EasySOA as easily as if they were stored locally.
    • Model synchronization:When files are transfered to EasySOA, their content shall be reflected to [EasySOA Core model](Final soa model design). In particular, the folowing information shall be taken into account:
      • workflow context information (see user story #1 above)
      • business process hierarchy (which processes are called from a given process)
      • service use by (technical) workflows
    • Constraints:
      • The feature shall be available when using "vanilla" (not EasySOA-branded) editors
        • at least the solution should provide a "fallback" mode to slightly modified editors, lacking some features but still providing file transfer.
        • at best the solution should provide partial or full functionality to any editor without requiring any change
      • Workflow files shall be versioned, i.e. each past version of the files shall be available as well as the current version.
      • (optional) An offline mode should be available, while keeping the data's consistency -- to avoid spreading data on several storages.
  • Meta-data, user comments on workflow files
    • We should still work on which meta-data may be useful to users.
  • Service connector settings retrieval
    • On modified editors, it shall be possible to retrieve service information based on the service name: endpoint URL, port name, operations, ...
    • One shall be able to use the retrieved information to automatically fill service connectors settings.

Impact on JWT

We'll add an integration layer on top of JWT that allows:

  • to browse services in EasySOA's repository directly from within JWT
  • to use EasySOA as a storage provider for "*.workflow" files (import and export)
  • to define a "context" for each Activity
    • references to objects in EasySOA, e.g. the modeled system
    • the supporting platform, e.g. scarbo/bonita runtime, a Liferay-based customer portal, or simply human processes
Add a custom footer
Add a custom sidebar
Clone this wiki locally