Re: Cross-application transactions in middleware systems

first, BizTalk is not middleware. it is an XML based solution for HTML driver interaction.
now, some good examples of middleware:

    Vitria            www.vitria.com
    NEON        www.neon.com
    MQSeries    www.ibm.com
    BEA             www.beasys.com

one goal of middleware is to be able to create a unified front end for users to a diverse array of other disparate applications (usually various legacy systems). perhaps, there is an HR system, a Payroll system, an Asset Tracking system, and an Accounting system [btw - this comes from several real world environments i have been at].

one day, the executive management team finally says, "Enough is enough! Why can't the staff access each of these systems from one screen? Any why can't the HR system update the Payroll system when a change is made? Why do we have double, triple, and quadruple keying of the same data and the same data stored differently in every system???" so goes the ranting and violla...the CIO/CTO has a new project...make all of the existing systems behave as they were one system.

enter stage right...Middleware Man...! current middelware offerings propose to solve this very problem. of course, there is some work to be done to achieve this panacea of the universal One. each transaction in each system has to be mapped and resolved. data models and data dictionaries for each system have to be on-hand. then mapping and transformation rules are defined... but never fear, middleware man is here! middleware purpots to make this possible...and maybe even easy (well, easier perhaps).

after all the work is done (and we have retired) and the system is rolled out, when Bobby Sue gets a $0.50 per hour raise, the Payroll system will now deduct an additional $0.75 from Bobby Sue's paycheck (that $0.50/hour pushed Bobby Sue into a higher tax bracket), Asset Tracking knows Bobby Sue now gets a new fangled mouse pad with the raise and issues the job order to deliver it, and Accounting/GL will have payroll actuals as soon as payroll runs, etc...etc..etc..

now we say, "but wait! what if HR updates the hourly rate and Payroll is down...or the network is down...or the database is down...or the red switch is down...???" what is enforced by the middleware is distributed transactional integrity (more complex than the ordinary transactional rules). however, the middleware allows each individual transaction to have its own set of rules defined, such as "all or none", "anything you can", "retry x and then rollback", "place in pending queue, wait n time units", etc, etc., etc... each system can have its own "transaction logic" for each enterprise transaction.

what should become clear is that we are looking at a "business transaction" rather than a database transaction. most of these transactions are invoked through the existing application logic, whether that be by APIs, RPCs, DCOM, screen scraping, or other such mechanisms. the implication is the middleware need not be concerned with the details of transaction execution on a given system, only with the proper call and response for each invocation and how to handle incorrect or unexptected responses. execution on a given system is done just as it would have been if it were a single transaction on that system in a stand-alone mode.

HTH "Judith" <judith.retief_at_iname.com> wrote in message news:3ac04e7a$0$254_at_helios.is.co.za...
> I'm a bit of a newby in the middleware sollutions field and have a
 question
> on transactioning in such an environment. If a more relevant group than
> comp.databases.theory exists, my apologies - I would appreciate a pointer
 to
> such a group.
>
> Middleware solutions such as BizTalk and mirriads of others promise to
 make
> available a single platform for the publication of third party services to
> client applications. Often these systems encorporate transactioning.
>
> What I would like to know is how these systems handle transactions.
> Transactions of which all the operations are executed within a particular
> server is ok, because the server iteself implements the resource locking,
> rollback, committing etc. But what about when the operations are to be
> executed by different servers? Then the middleware has to take
> responsibility for all the classical transactioning issues of resource
> locking etc. But that can only happen if the servers expose their internal
> algorithms for handling these issues, which they usually don't (as far as
 I
> know).
Received on Sat Apr 21 2001 - 04:55:23 CEST