Engineering workflow elements
This presentation is the property of its rightful owner.
Sponsored Links
1 / 31

Engineering workflow elements PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Engineering workflow elements. Machiel Jansen E-science support SARA Amsterdam. Who am I. Living in Baarn with Jacqueline No pets…but. Who am I. Education Psychology: Artificial Intelligence Philosophy: mainly logic. Computer Science

Download Presentation

Engineering workflow elements

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Engineering workflow elements

Engineering workflow elements

Machiel Jansen

E-science support

SARA Amsterdam

Who am i

Who am I

Living in Baarn

with Jacqueline

No pets…but

Who am i1

Who am I

  • Education

    Psychology: Artificial Intelligence

    Philosophy: mainly logic.

    Computer Science

    PhD on Formal explorations of knowledge intensive tasks.

And now

And now…

Work: IPS, Getronics, UvA,

VU (VL-e), Collexis, SARA

Languages: Java, Prolog, and many more I try to forget.

Fields of expertise: Knowledge representation, logic, information retrieval, software engineering, formal languages, Grid, cognition and as a hobbies: Dutch architecture, art history, literature, birds, plants and history in general.

And now1

And now…

E science


  • E-science is about sharing and collaboration

  • It aims for generic software components on a shared infrastructure

  • In BioAssist this should be realized by means of Grid, webservices and workflow

Sharing and collaboration

Sharing and collaboration

  • Sharing data and sharing functionality

  • Sharing involves agreeing on common formats and the meaning of the information shared

  • It involves the setting up of contracts for the functionality of software artefacts

  • Sharing means that software should be generic and reusable

Workflow and web services the vision

Workflow and Web ServicesThe vision:

Workflow and Web Services offer you a way to share and collaborate.

You publish and share Web Services and use others. (The same with workflows).

But what are Web Services?

Let’s limit it to SOAP/WSDL…..

Engineering workflow elements

  • Originally Simple Object Access Protocol but now SOAP stands for SOAP!

    • (Called XP for XML Protocol for a while)

  • Originates from doing Remote Procedural Calls over XML and HTTP

  • Microsoft initiated but moved to W3C

  • Originally a number of competitors

    • XML-RPC etc…


Remote procedural style

myVar= foo(“hello world”, 6)

String foo(String s, Integer i) {

return result;


Remote Procedural Style

Remote procedural style1

myVar = foo(“hello world”, 6)

String foo(String s, Integer i) {

return result;


Remote Procedural Style


Remote procedural style2

myVar = foo(“hello world”, 6)

String foo(String s, Integer i) {

return result;


Remote Procedural Style


Soap web services

SOAP Web Services

  • Independent of Programming language

  • The objects that you send are serialized and “marshalled” in XML.

  • XML data is received, validated and processed.

  • SOAP is a way to do RPC. But not the only one.

Web services in workflow

Web Services in workflow

  • In workflow WS are just workflow elements. In Taverna WS can be replaced by local programs or other technical implementations.

  • Each workflow element should be generic. This means it can play a role in more than one application.

  • Workflow can be seen as big abstract programs and the Web Services are as generic software modules.

Important issues

Important issues

  • How do you identify Workflow Elements?

  • They should play a role in more than one workflow

  • They should be independent of other workflow elements

  • They should be elegant and easily used

More important issues

More important issues

  • They should be resistant to change

  • They should have a clear interface to the outside world.

Identifying workflow elements

Identifying workflow elements

  • Workflow elements are high level objects. Use OO techniques and engineering

  • Start big and partition into smaller chunks and apply the criterion for loose coupling and high cohesion.

Loose coupling

(Loose) coupling

  • This is the criterium for independence between elements (objects).

  • Loose coupling means independency. Loosely coupled components do not rely on each other.

  • How well are they separated?

  • A workflow element normally is completely decoupled from any other until you create the workflow. Then you couple elements together.

Workflow coupling

Workflow coupling

  • Workflow elements may be coupled in time, meaning the availability of one system does affect the other. (Synchronous WS!)

  • Workflow elements may be coupled in format, meaning that differences in data models do have to be resolved to achieve integration.

  • Workflow elements may be coupled in function, meaning that their separate use is not very useful (or likely).

Data coupling

Data coupling

  • What comes out one workflow element must be reformatted before it is send as input to the next.

  • In Taverna: shims and beanshells. In WS this is very hard to go around. WS are stateless.

  • In OO you use decoupling techniques like factories and dependency injection?

Factories and dependency injection

Factories and dependency injection

  • Briefly…

  • Suppose a class that listst movies. It should be independent of HOW the movies are stored.

  • Create an interface which publish an abstract method. Then give different implementations

  • Inject the needed implementations in the class that uses a movie lister.

    Wanna know more? Read Fowler, use Spring, read Design Patterns.

Engineering workflow elements


Engineering workflow elements


  • Suppose your WS returns a list of proteins.

  • Another WS wants it tab-delimited, another in XML. How you deal with that? Do you at all?

  • If not, the workflow programmer has to write a shim. But it’s the job of the workflow engine to wire workflow elements. The shim means tight data coupling.

  • You can provide different methods, but then the interface publishes non-functional details. For each new type the interface changes!

  • What you want is to that the workflow engine does the wiring. It should first set the type in the service (injection) and then make a general call for a protein list.

  • But WS are stateless. Still, this is food for thought.



  • Cohesion is about how the activities within a single module are related to one another.

  • Cohesion is the measure of the strength of functional relatedness of elements within a module.

High cohesion

High cohesion

Functional cohesion

Functional cohesion

  • If you can sum up everything that the module accomplishes as one problem-related function, then that module is functionally cohesive.

  • A functionally cohesive module contains elements that all contribute to the execution of one and only one problem-related task.


  • Reuse is good.

Cohesion and workflows

Cohesion and workflows

  • A workflow element should be a functional cohesive unit on a high level of granularity.

  • If a workflow element is highly functional cohesive it can be used in many different workflows.

Sequential cohesion

Sequential cohesion

  • A sequentially cohesive module is one whose elements are involved in activities such that output data from one activity serves as input data to the next.





  • Reuse is mor problematic. The activities do not form a functional enitity

Procedural cohesion

Procedural cohesion

  • A procedurally cohesive module is one whose elements are involved in different and possibly unrelated activities in which control flows from each activity to the next. (Remember that in a sequentially cohesive module data, not control, flows from one activity to the next.)







    Such modules are hard to reuse. They may fit in a specific scenario.

The problem with workflow elements

The problem with workflow elements

Workflow elements are not Web Services by definition. They are generic loosely coupled, functional cohesive, generic software modules.

This means that a proper workflow element should be able to be easily used in different kinds of workflows.

This is difficult!



  • Organizational -- developing reusable software requires a deep understanding of application developer needs and business requirements. As the number of developers and projects employing reusable assets increases, it becomes hard to structure an organization which can provide effective feedback.

  • Economic -- Developing reusable system takes more effort and time, and hence money. These investments should pay off later.

  • Administrative -- Although it's common to scavenge small classes or functions opportunistically from existing programs, developers often find it hard to locate suitable reusable modules outside of their immediate workgroups.

  • Political -- Groups that develop reusable middleware platforms are often viewed with suspicion by application developers, who resent the fact that they may no longer be empowered to make key architectural decisions. Likewise, rivalries among different may prevent reuse.

  • Psychological -- application developers may also perceive “top down” reuse efforts as an indication that management lacks confidence in their technical abilities. In addition, the “not invented here'' syndrome is ubiquitous in many organizations, particularly among highly talented programmers (reinventing the wheel).

  • Login