Jan Algermissen wrote: >To me a transaction means (in the context of these discussions) a >sequence of operations that somehow belong together. IMHO a >transaction is essentially allways procedural (even if you call it >workflow and express it in any of the BPxx languages). I think it is >allways about doing this and that in such and such sequence. > >Having said that, what does the 'process oriented' add in your >sentence? Are there transactions that are not processes (or parts of >processes)? > > There are different sorts of "transactions". What people typically have in mind when they refer to "complex process-oriented business transactions" are the kind of long-running business transactions dealt with by (for example) ebXML BPSS:
> BPSS is a relatively simple but effective schema that describes public > processes only. In a BPSS model different roles (seller, buyer, etc.) > collaborate to carry out a set of transactions. The orchestration of > the transactions is defined using a control flow based on UML activity > graph semantics. There is no explicit support for describing how data > flows between transactions. > > The transaction part of the model is based on a proven, robust model > for long-lived e-commerce business transactions used by previous B2B > standards such as RosettaNet. There is explicit support for specifying > quality-of-service semantics for transactions such as authentication, > acknowledgements, non-repudiation, and timeouts. For more details, see > http://www.ebxml.org/specs/ebBPSS.pdf. > However, there are other kinds of "long-running business transaction" than those dealt with by such standards. There is more to business than order-to-cash and supply chain! How about Product Lifecycle Management? IT Outsourcing? Complex Sales? Marketing? Company growth/merger? Health care? Human resources? And this is to say nothing of processes that are not specifically business-oriented but are nevertheless at the root of our society: political/social negotiation, disaster prevention/management, crime solving, epidemic control, government policy implementation, running an election campaign, military action, and so on. Perhaps if we dealt with such processes more efficiently with the aid of IT the world would be a better place to live in. However, few people would try to describe such dealings using a language such as ebXML - and if they did, they would be wasting their time. These other kinds of transaction can be supported by computer systems, but you need a framework that is less mechanistic. Please understand that I am not in any way criticising BPEL/WS-CDL, BPSS, or any other current standards. It is horses for courses, and these techniques are not suited to the kind of collaborative, human-driven processes described above. For such processes, you need to start from an understanding of human nature and the way that we collaborate, not from computer and network principles. If you do this, you find that there are other kinds of transaction, and ways to manage them using IT. -- All the best Keith http://keith.harrison-broninski.info ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
