I wrote the following notes some time ago as a way to share information about the subject of middleware and service-oriented architecture. I think I began by asking the questions 'what is middleware?' and 'what can it do for us?', explicitly in the context of making information systems that can help to support the delivery of useful services to support learning.
I should add a disclaimer: some of the stuff that is presented here is quite technical and seems quite a long way away from my earlier posts that relate to accessibility, but there are connections in terms of understanding how to build information systems that can help an organisation to manage the delivery of accessibility services (such as the loan of assistive technology).
Beginning my search
I began by exploring a number of definitions. I first attacked the notion of workflow (Wikipedia). What does workflow mean? Is it one of those terms that can have different meanings to different people? I rather like the Wikipedia definition, which goes:
- A workflow is a reliably repeatable pattern of activity enabled by a systematic organization of resources, defined roles and mass, energy and information flows, into a work process that can be documented and learned. Workflows are always designed to achieve processing intents of some sort, such as physical transformation, service provision, or information processing.
I then asked myself, 'how does the idea of workflow relate to the notion of middleware?' (I had heard they were connected, but wasn't quite sure how). Again, the Wikipedia definition of middleware proved to be useful:
- Middleware is the software that sits 'in the middle' between applications ... stretched across multiple systems or applications. ... The software consists of a set of enabling services that allow multiple processes running on one or more machines to interact across a network. This technology evolved to provide for interoperability in support of the move to client/server architecture. It is used most often to support complex, distributed applications. ... Middleware is especially integral to modern information technology based on XML, SOAP, Web services, and service-oriented architecture.
So, these two ideas are connected. Carrying out workflow may involve making use of a number of different services, which might be able to call through some sort of middleware...
Further links
A little more digging pointed me to a number of other directions. Clever people have proposed something called BPEL, an abbreviation for Business Processing Execution Language. Wikipedia is again useful:
- WS-BPEL (or BPEL for short) is a language for specifying business process behavior based on Web Services. Processes in WS-BPEL export and import functionality by using Web Service interfaces exclusively.
On this page, there is a link to a blog post which is a very good primer and introduction. It is lots more clearer than the Wikipedia page.
I found the following text to be useful:
- In BPEL, a business process is a large-grained stateful service, which executes steps to complete a business goal. That goal can be the completion of a business transaction, or fulfilling the job of a service. The steps in the BPEL process execute activities (represented by BPEL language elements) to accomplish work. Those activities are centered on invoking partner services to perform tasks (their job) and return results back to the process.
Interestingly, it also contained the following:
- As for limitations, BPEL does not account for humans in a process, so BPEL doesn't provide workflow-there are no concepts for roles, tasks and inboxes.
We are almost at the point where the same terms may be used to mean different things. Perhaps there is a difference between what workflow is and what business processes are? Michelson (the blog author) seems to equate workflow with 'things that people do'. The point is that a wide definition of workflow can include things that BPEL does not.
At this point, I was wondering, 'if I have a process (say, a task that I have to complete), where half of the task has to be completed by a machine and the other half has to be completed by a person, then what technologies should I use?'. All is not lost. The blog mentions there is something called BPEL4People (Wikipedia), and contains a link to an IBM whitepaper.
I've extracted some fragments that caught my eye:
- The BPEL specification focuses on business processes ... But the spectrum of activities that make up general purpose business processes is much broader. People often participate in the execution of business processes ...
Following this, I stumbled across the following scenario:
- Consider a service that takes place out-of-sight of the initiating process. In many circumstances, it may be immaterial as to whether the service is performed with or without user interaction, for example, a document translation service.
This made me wonder about my own involvement in the EU4ALL project, which is exploring processes that enable lecturers to order alternatives formats, such as tactile maps or other kinds of materials, for instance.
Application Servers
BPEL is represented using something called XML (Wikipedia), which is, of course (more or less) a text file that has lots of structure (created by the enthusiastic use of angled brackets).
BPEL is not the only way to represent or describe business processes (or workflow). Another approach might be to use something called State Chart XML (SCXML), for instance. There are probably loads more other data structures or standards you might use.
At this point, you might be asking, "okay, so there are these magic XML data structures that allow you to describe entire processes but how do you make this stuff real so people can use it?". The answer is use something called an Application Server (Wikipedia).
Here, I am again lazy and quote from Wikipedia:
- Application server products typically bundle middleware to enable applications to intercommunicate with dependent applications, like web servers, database management systems ...
Although an application server may be able to run middleware (and potentially sequence the order in which activities are carried out), we need to add interfaces so people can interact with it.
Always being the pragmatist, I asked myself another question, 'all this sounds like good fun, but where can I find one of these application servers that does all this magic stuff to manage our workflow and processes?' I don't have a precise answer to this question, but I did find something called Apache ODE.
To quote from the project website,
- Apache ODE (Orchestration Director Engine) executes business processes written following the WS-BPEL standard. It talks to web services, sending and receiving messages, handling data manipulation and error recovery as described by your process definition. It supports both long and short living process executions to orchestrate all the services that are part of your application.
Another distinction (as opposed to long and short running processes) include processes that require human intervention (or actions) and those that can run on their own, such as executing a database query or sending messages to another part of a large organisation to request the availability of resources.
All this sounds great! All I have to do now is to find some time to study this stuff further.
Other approaches
Whilst reading all this stuff, the purpose of other products that never made sense to me started to become clear. A couple of years ago, I had heard something called Biztalk mentioned, but never properly understood what it was. Again, Wikipedia is useful, describing Biztalk (Wikipedia) as
- a business process management (BPM) server. Through the use of "adapters" which are tailored to communicate with different software systems used in a large enterprise, it enables companies to automate and integrate business processes.
I've not looked into this very deeply, but it also seems that the House of Microsoft might have concocted something of their own called the Windows Workflow Foundation (Wikipedia) which I understand also connects to the topic of BPEL.
Of course, there's a whole other set of terms and ideas that I haven't even looked at. These include technologies and ideas such as an enterprise service bus (ESB), message queues, message-oriented middleware (MOM), the list goes on and on...
A summary (of sorts)
The issue of service-oriented architecture design goes a lot deeper than simply creating a set of solitary web services running on different systems. Designers need to consider how to ensure that messages are received successfully, how to consider or address redundancy and how to measure or ensure performance. The ultimate choice of architectural components and elements depend very much on your requirements, the boundaries of your organisation, your needs for communication and who you need to communicate with.
What I found surprising was the number of technologies that could be potentially used within the project that I'm currently working on. The ultimately choice of technologies are likely to boil down to the key issue of: 'what do we know about right now', and 'what is the best thing we can do'.
Footnote
I was going to add a footnote to one of the earlier sections, but because my notes have turned into a blog post, I've decided to put it here.
I like this stuff because it reminds me of two areas that always fight with each other: software maintenance and business process re-engineering. Business practices can change more quickly than software systems. The need for process flexibility (and abstraction) is one motivation that has driven the development of things like SOA and BPEL.
This stuff is also interesting because workflow is where the world of 'work' and the world of software nearly combine. There is another dimension: would you like a computer telling you what to do? Also, no matter how much we try to be comprehensive in our understanding of a particular institution there will always be exceptions. Any resulting architecture should ideally try to accommodate change efficiently.
Middleware (in some senses) can have a role to play in terms of gathering information about the performance of services, i.e. how long it takes for certain actions to a certain kind of request, and has the potential toe manage the delivery of interventions (such as issue escalation to supervisors) should service quality be at risk.
Acknowledgements
Blog image is a modified version of the one found on the Wikipedia SOA page. I also cheekily consulted an O'Reilly book when I was preparing an earlier version of these notes, but I've long since returned it to the library (and I can't remember its title).