The following white paper offers a pragmatical approach to SOA vs Workflow automation and
addresses real life issues about the implementation of such an environment by presenting a
methodology and comparing the available technologies and standards.
As a full member of the Workflow Management Coalition (WfMC) ADVANTYS is directly involved in the definition of the workflow standards. It's WorkflowGen workflow software has been designed according to the latest standards and offers a solution perfectly in line with a SOA.
SOA: Another acronym for a new technology?
Information Technology is becoming more than ever a science in its own right, new architecture for designing information systems uses real mathematical formulae which are difficult for neophytes to understand:
SOA = (EDI + EAI + XML + BPM) x WEB
However, the needs expressed by organisations are very simple:
How can we organise and optimise our business processes?
Just a few years ago, the answer to this was also very simple: Workflow.
Today however, several solutions to this question are possible;
- Standardise exchanges of information between different information systems with EDI (Electronic
Data Interchange) and XML documents using EAI (Enterprise Application Integration) solutions.
- Automate the circulation of information and optimise processing with a BPM (Business Process
- Integrate these changes with Web standards such as HTTP protocol and Web Services.
As if this were not enough for companies to think about, it is now recommended that companies reorganise
their system architecture in the form of “Services”. Moreover, to complicate this task further,
more than twenty more or less competitive ‘standards’ are available…
After 10 years of laborious migrations to object-oriented applications and 3-tier architecture, must companies really start again from scratch?
Are SOA and Workflow synonymous, complementary or competitive?
How can the needs for optimisation of processes be met immediately, whilst also integrating the latest techonologies?
Presentation of SOA
In basic terms, Service-Oriented Architecture is an approach to implementing applications based on the use of ‘services’. The ‘service’ is a re-usable component available either on the internal or external company network. This component takes the form of a Web Service, which means the architecture can be fully modular, independent of the services host platform and also enabling it to be based on standards such as HTTP, XML and SOAP.
The Web Services provider can therefore easily offer “consumer” applications either internal or external to the company, with easily integrated functionalities via applications regardless of the medium: Rich Client (Windows), Thin Client (Web) or Mobile Client (PDA).
The application which consumes web services can “cherry pick” supplier’s functionalities,
independently of where they are located on the network, or of the technologies and databases used.
The provision of a directory of Web services means that the most appropriate services for specific needs can easily be found.
This concept is not a new one, the ‘object brokers’ DCOM and CORBA already provide these types of services. The SOA is materialising through its large-scale adoption using software of solutions for standards such as XML and Web Services, and these technologies have made it possible to create complete applications. SOA’s goal is therefore to make the creation and consumption of web services a systematic feature of the company’s I.T. system architecture.
It is recommended that services be processed individually in order to improve their re-useability in different, more complex work processes, also called business processes.
It is therefore important that all necessary tools and standards be acquired rapidly in order to model and organise the execution of the various services.
We thus arrive at the heart of the problem:
Is the SOA a re-invention of Workflow?
From a marketing point of view: the concept of ‘orchestrating’ web services is a little too abstract for companies, optimising business processes is far more explicit. EAI software designers oriented towards XML and Web services have naturally turned to SOA for a clear answer to a customer need.
However, most of this software still specialises in the Workflow of automatic processes : completely automated synchronous or asynchronous processes. We are therefore still in the realm of the EAI.
From a technical point of view: The SOA is an impressive platform for Workflow software. In fact, most BPM solutions can “consume” web services to execute automatic processes. From the opposite perspective, a process managed by a workflow engine can be seen as an asynchronous web service by another application. These functionalities are enabled using WFMC and OASIS standards such as ASAP and WF-XML 2.0.
An organisation which implements a Service-Oriented Architecture will therefore considerably optimise its processes managed by the Workflow solution.
Should an SOA be implemented before using a Workflow solution?
This is not necessary, indeed it is not recommended. In fact, the Workflow project enables the
company processes to be accurately modelled and also emphasizes the automatic processes which will be the future Web Services of your SOA.
The implementation of workflow software is a natural step towards evolving your information system into SOA.
Furthermore, from the point of view of the end-user, a web service still remains something which is difficult to materialise. Chronologically, you can therefore respond to immediate needs for optimisation of your processes with a workflow engine, then optimise your automatic processes by building SOA.
Managing your workflow project with SOA in mind
It is too early yet to imagine the implementation of fully automated work processes. The fact is, collaborative project management and outsourcing both entail a significant number of human operations (especially of the approval type).
In most administrative processes, automatable operations in the form of web services are still rare exceptions. However, the most significant productivity increases will be generated by such operations.
For example, the implementation of a workflow system for a process of purchase request validation will result in a considerable increase in productivity. Automating the operation for registering a purchase request validated in the ERP using a web service, for example, saves even more precious time and eliminates the risk of input errors.
Finally, responsiveness is a key element, the processes must therefore be adaptable according to internal or external changes in the organisation.
It is therefore particularly important to integrate these parameters into your workflow implementation method whilst also focussing on building your SOA architecture.
Here are a few of the important steps to ensuring success in this type of project:
Make an inventory of your processes
Most of the time, your workflow project is limited to the implementation of a process. However it is very interesting to look objectively at all your processes (by department, field, etc.).
This step will enable you to identify the automatic processing operations that are common to different
processes. Thus, when you are creating these ‘services’ you will be able to anticipate their reuseability, by avoiding situations where, for example, they would be too highly specialised with regards the consumer process.
Work by process version
In some cases, web service creation can represent a substantial sub-project in terms of your workflow.
This can noticeably lengthen the workflow creation process, for example, due to a problem of
resources for analysing and developing the web service. Automating a process with a workflow engine can lead to a significant increase in productivity and quality of service.
Wherever possible, it is therefore appropriate to launch a version 1 (as part of the pilot project for example) with simple web services. The production of this version 1 can also feature any
improvements or changes compared with initial plans for the web service.
Design a SOA Manager
The number of web services is set to increase sharply, along with the number of consumers. As with databases, it is important that your “library” of web services be organised efficiently.
First, a person should be designated responsible for updating the directory of available web services (description, version, security, etc.) including their use internally and possibly externally to the company. This is also the occasion for ensuring a level of quality monitoring especially in terms of standardisation parameters, performance, availability and security.
To summarise, a pragmatic approach to these new technologies will enable you to achieve your workflow objectives whilst also evolving towards the SOA scenario. The efficient implementation of SOA requires a certain measure of corporate maturity vis à vis automation of company processes.
However, in the current context, aiming to carry out all tasks simultanously, with a single tool and using the same developer profiles seems to be particularly difficult.
SOA standards or workflow standards: what's the best?
As mentioned above, Service-Oriented Architecture constitutes a particularly powerful platform for accelerating and optimising the mangement of these Workflows.
Here were are talking about different levels of modelling and execution. However, there are many common points, or even overlaps, between BMP/Workflow and SOA.
The problem today actually lies with the relative competition between standardisation organisations.
In fact, web service standards, XML, EAI and EDI converge in particular towards BPM and workflow.
Historically, WFMC was the precursor in this field, in particular with XPDL which defined processes and WF-XML for inter-application exchanges. The association with OASIS to create the ASAP protocol constitutes a cross-over point with the other Web service type standards
In the field of BPM, the “standard stack” is becoming increasingly difficult to understand. The
positioning of BPEL in relation to XPDL and BPML is a perfect example of this.
This multiplication of standards (BP.., WS..) whilst on one hand being presented as SOA, BPM or Workflow standards, poses a real problem when choosing a standard or, more likely, a combination of standards in order to build the technical solutions for managing the company’s processes. In the long term, the arrival of major actors on the market will resolve these problems de facto.
Meanwhile, increasing process automation needs must be met. A conservative approach is to use the Workflow and SOA “core” standards, that is, the Workflow model defined by the WFMC and the Web Services through SOAP.
More specifically, SOAP for inter-application communications, XPDL for defining processes, BPEL for organising web services and ASAP for managing asynchronous services are standards which make the implementation of workflows easier to integrate into an SOA architecture.
Technical challenges of SOA
The major issue with SOA architecture is the level of services offered by the web services. SOAP is simultaneously over-simplistic and over-complicated.
Too simplistic to handle issues of security, adressing and availablility, yet too complex to be
2 distinct trends can therefore be noted: on one hand, a profusion of new specifications and standards (WS…) to provide the functional elements lacking in SOAP; on the other, simpler alternatives such as REST.
Should we conclude therefore that this architecture is still in its infancy?
Conceptually speaking, no, because the creation of collaborative and shared applications responds to the realities of todays’ information systems. The increasing use of technologies and Web standards is undeniable. From a technical point of view, it is clear that packaged solutions are emerging on standards that are currently still under development. The best way to avoid future problems related to choice is to re-organise your SOA project within a functional framework, that is, to optimise business processes and therefore the Workflow project.
Current Workflow solutions include numerous pre-packaged, stable functionalities for automating your processes. They enable immediate use of web services for carrying out automatic processes without the need to acquire additional tools
Service-Oriented Architecture is clearly the solution for organising information systems, responding on various levels to new development and communication challenges in applications.
The work involved in system migration and choosing the appropriate moment to effect this migration are the main obstacles to rapid implementation in companies.
To restrict SOA implementation to a single technical migration project could both impede its
acceptibility in terms of budgetary concerns whilst also running the risk of choosing badly between solutions still in their infancy.
On the other hand, integrating Web services in Workflow projects to perform automatic processes is the most pragmatic solution for gradual and efficient implementation of SOA in terms of ROI.
The expertise and work of the WFMC have contribued significantly to this field. Collaboration with other standardisation organisations has enabled integration of the full functional and technical aspects.
However, the emerging form of competition must not be allowed to reduce the number of similar standards by squeezing them out of the market.
Workflow, BPM and SOA are therefore not competitors but the proliferation of marketing and
techniques surrounding automation of processes are such that solutions are particularly difficult to understand from the client companies’ point of view.
In this particular context, those solutions presenting tools which are easiest to implement and use will almost certainly have the highest rate of success.