Lambda the Ultimate

inactiveTopic IBM releases web-services flow language
started 5/24/2001; 9:41:21 AM - last post 5/24/2001; 1:07:21 PM
Ehud Lamm - IBM releases web-services flow language  blueArrow
5/24/2001; 9:41:21 AM (reads: 1289, responses: 1)
IBM releases web-services flow language
(via xmlhack)

Apparently the language is to be used to describe the composition of web services, which seem to be something like service combinators:

Composition comes in two types: The first type allows to specify the logic of a business process; the second type allows to define the mutual exploitation of Web services of participants in a business process. A brief concepts of composition sketch is provided in an introductory chapter of the document. A detailed discussion of the metamodel behind composition follows. The language proper is described and illustrated by code snippets, followed by an XML schema of the language.

I haven't been able to download the paper, so do let me know if it is any good.

Posted to xml by Ehud Lamm on 5/24/01; 9:42:37 AM

John Lawter - Re: IBM releases web-services flow language  blueArrow
5/24/2001; 1:07:21 PM (reads: 705, responses: 0)
I've read some of the paper, and I think it's interesting, although not necessarily from a language theory point of view. I'd say it's worth at least a skim for someone working in business-centric application development.

There seems to be a growing movement towards the use of "rules" in enterprise computing. The most recent meeting of the NYJavaSIG dealt with another platform for defining business rules, and I remember one of my professors in graduate school doing work on modelling business processes using constraint logic. The basic idea behind business rules in general is that a non-technical user could specify how abstract business processes work in a kind of declarative language, which could be used to chain together primitive operations.

I think this presents a real step forward. By having end-users clearly specify business processes, it makes it easier to develop specifications, and by removing implicit semantics from functions, it can make code less brittle and easier to maintain. It could also make declarative and logic languages more mainstream, which might not be such a bad thing.