Originally posted by jay vas:
When working on large projects, I always look to the relational data model as the "end point" i.e., the place which gives immediate relevance, structure, and scalability to any software component in a system. But it seems like these WSDL BPM XPDL types only reference databases as secondary services in their frameworks, making it difficult to understand what it is that is being solved by their frameworks.
This actually suggests that you are "data-(structure-)oriented". The database is the crown-jewel of the corporation but without process/behavior that data serves nobody just like process cannot produce results without data. WSDL exposes operations which imply that they are based on data; the data-structures exposed are limited to the ones that are necessary to communicate with the operations - the relational model is hidden away, "encapsulated" so that it is free to change in response to pressures unrelated to the operations that are exposed in the WSDL.
A workflow engine facilitates "workflow" by orchestrating (i.e. it is the conductor) the interactions between disparate document sources and sinks. Now your document sources and sinks could simply be databases - however that would mean that the workflow is providing
all of the process (unless you are using DB stored procedures). However a good workflow engine should also be able to use existing business logic that may already exist as components or services, using them as document source and sinks and access them with the required interfacing technologies (JAR, RMI, IIOP/CORBA, COM, DCOM, TCP/IP, HTTP,
SOAP, etc.). It also needs document transformation and aggregation facilities so that it can feed the output from one or more document sources in a reformatted fashion into another document sink. So in fact the workflow is largely procedural. A workflow instance may need to track its current position in the flow and it may even have to buffer some documents that have already beed produced and won't be used until later - but is doesn't have "state" in the object sense, especially considering that the flow usually simply starts and runs to completion or fails (rather than exposing an "interface protocol" as an object does to its clients).
It may be worth your while to skim through J�rgen Thelin's:
A Comparison of Service-oriented, Resource-oriented, and Object-oriented Architecture Styles, especially the slides following "Comparison of 3 Distributed
Architecture Styles" (Slide 37).
Object-Orientation is tightly coupled which means it is suitable for closed systems under the control of a single "owner". Resource-Orientation is loosely coupled due to the universal (CRUD) interface and suitable for "read-mostly" data that can be linked to between different "owners" Service-Orientation is loosely coupled*** and suitable for sharing a system between owners. (*** a lot of the loose coupling is lost on the client side when you bind the service contract "early" through the use of a code generator to an OO interface)
The point being is that OO isn't always the right tool for the job. It is great for managing complexity in "closed" systems but the fact that objects (as well as services) have to be interacted through an "arbitrary" interface (i.e. specific to that class) leads to tight-coupling that can be difficult to deal with in "shared" systems (See also
Transitioning From Object-Oriented to Resource-Oriented Programming; while a bit extreme I can see his point).
Now if you are saying that you see workflow engines exclusively used to pluck data out of one database, transform it (i.e. apply some business logic) and then stuff it into another database then I would tend to agree with you - I don't think workflow engines were supposed to be used for "micro-managing" business logic at that level; I'd imagine that the resulting set of workflows could become unmanageable quite quickly. Better to compartmentalize the business logic and implement it in a technology (OO solution, Business Rule Engine, etc.) more capable of dealing with the complexity in such a way that it can be shared by many workflows.
Then of course there is the matter of audience. While it will take software developers to implement business logic components and services, I don't think that people creating the workflows for workflow engines were supposed to be software developers - even though developer skills are definitely an asset.
[ April 18, 2008: Message edited by: Peer Reynders ]