Click here to close now.

Welcome!

@MicroservicesE Blog Authors: Pat Romanski, Lori MacVittie, Elizabeth White, Liz McMillan, XebiaLabs Blog

Related Topics: @MicroservicesE Blog

@MicroservicesE Blog: Article

Business Transaction Protocol: Transactions for a New Age

Business Transaction Protocol: Transactions for a New Age

Use of atomic transactions is a well-known technique for guaranteeing consistency in the presence of failures. The ACID properties of atomic transactions (Atomicity, Consistency, Isolation, Durability) ensure that even in complex business applications consistency of state is preserved.

Transactions are best viewed as "short-lived" entities operating in a closely coupled environment, performing stable state changes to the system; they are less well suited for structuring "long-lived" application functions (e.g., running for hours, days, etc.) and running in a loosely coupled environment like the Web. Long-lived atomic transactions (as typically occur in business-to-business interactions) may reduce the concurrency in the system to an unacceptable level by holding on to resources for a long time; further, if such an atomic transaction rolls back, much valuable work already performed could be undone. As a result, there have been various extended transactions models where strict ACID properties can be relaxed in a controlled manner. Until recently, translating these models into the world of Web services had not been attempted. However, the OASIS Business Transaction Protocol, specified by a collaboration of several companies, has tried to address this issue. In this article, the second in a two-part series, we'll describe how the BTP has attempted to solve these problems.

Architecture of the Business Transaction Protocol
A very high-level view of the BTP can be described as follows: Web services do work within the scope of atoms, which are created by the initiator of a business transaction; multiple atoms are composed into a business transaction (e.g., arranging a holiday) by a cohesion composer such that different atoms may possess different outcomes, as directed by the business logic, e.g., cancel one insurance quote and confirm another. Businesses take part in atomic or cohesive transactions via participants, and both cohesions and atoms use coordination to ensure that participants see the desired outcome (see Figure 1). This may seem fairly straightforward at first, but as we shall see in the following sections, there's a lot more going on under the covers!

 

The XML Context
In order for a transaction to span a distributed number of services/tasks, certain information has to flow between the sites/domains involved in the application. This is commonly referred to as the context and typically contains the following information:

  • A transaction identifier that guarantees global uniqueness for an individual activity. (Such an identifier can also be thought of as a "correlation" identifier or a value used to indicate that a task is part of the same work activity.)
  • The transaction coordinator location or endpoint address, so participants can be enrolled.

    The context information is propagated to provide a flow of context information between distributed execution environments, for example using SOAP header information. This may occur transparently to the client and application services. The context is propagated as part of normal message interchange within an application (e.g., as an additional part of the SOAP header).

    XML Message Sets and Carrier Bindings
    In the Web services world, information is communicated in XML documents, but how those documents are exchanged may be a function of the environment, business relationship, etc. Therefore, although BTP mandates that its own information (context and protocol messages) must be carried in XML payloads, it doesn't specify how these payloads are transmitted; it doesn't mandate a specific carrier protocol.

    Obviously, without a carrier protocol, BTP is of very limited use! The technical committee did define a binding to SOAP 1.1 over HTTP 1.1 as part of the BTP 1.0 specification, but the intention has always been that other specific carrier protocol bindings to the BTP XML schema would be provided on an as-needed basis. So if, for example, a group of companies sees merit in defining a binding using pigeons(!), they could so define it and submit it as an appendix on optional bindings to the BTP specification.

    As with traditional transaction processing systems, the BTP message set is concerned with messages for driving the protocol and messages containing information for participating within the protocol. The former are typically of interest only to implementers of either BTP or participants, whereas the latter are of interest to service providers and their associated participants.

    Typically a BTP message is propagated within the body of the SOAP envelope. For example, Listing 1 shows a typical begin message.

    For application messages that also carry BTP content, the situation is different. In this situation the BTP messages are typically located within the header of the SOAP envelope, as can be seen in Listing 2, in which a BTP context is propagated with an application-specific method call.

    The Web Service
    Whenever a user contacts a Web service, e.g., a taxi booking service, whose work it wishes to be under the control of a transaction, components of the transaction system are responsible for flowing the context to that service. The service can then use this information to enlist a participant with the transaction. The service is responsible for ensuring that concurrent accesses by different applications are managed in a way that guarantees some internal consistency criteria for that service. Note that a Web service may also play the role of a participant.

    The Participant
    The participant is the entity that does the real transaction work. The Web service (e.g., a theater booking system) contains some business logic for reserving a seat, inquiring about availability, etc., but it will need to be back-ended by something that maintains information in a durable manner. Typically this will be a database, but it could be a file system, NVRAM, etc.

    Now, although the service may talk to the back-end database directly, it cannot commit or roll back any changes it (the service) makes, since these are ultimately under the control of the transaction that scoped the work. In order for the transaction to be able to exercise this control, it must have some contact with the back-end resource (the database in our example), and this is accomplished by the participant.

    Each participant supports a two-phase termination protocol via the prepare, confirm, and cancel operations. What the participant does when asked to prepare is implementation dependent (e.g., reserve the theater ticket); it then returns an indication of whether or not it succeeded. However, unlike in an atomic transaction, the participant does not have to guarantee that it can remain in this prepared state; it may indicate that it can only do so for a specified period of time, and also indicate what action it will take (confirm or undo) if it has not been told how to finish before this period elapses. In addition, no indication of how the prepare is implemented is implied in the protocol, so resource reservation (locking), as happens in an ACID transaction system, need not occur.

    The Coordinator
    Associated with every transaction type (atom or cohesion) is a coordinator, which is responsible for governing the outcome of the transaction. The coordinator may be implemented as a separate service or may be colocated with the user for improved performance. It communicates with enlisted participants to inform them of the desired termination requirements, i.e., whether they should accept (confirm) or reject (cancel) the work done within the scope of the given transaction. For example, whether to purchase the (provisionally reserved) flight tickets for the user or to release them. This communication will be an implementation-specific protocol (e.g., two- or three-phase completion).

    A transaction manager factory is typically responsible for managing coordinators for many transactions. The initiator of the transaction (e.g., the client) communicates with a transaction manager and asks it to start a new transaction and associate a coordinator with the transaction. Once created, the context can be propagated to Web services in order for them to associate their work with the transaction.

    The atom coordinator is typically used to scope work performed on Web services. The cohesion composer is the business logic for gluing together the flow of the application into one or more atoms. Although Web services do work within the scope of a specific atom, it is the composer that ultimately determines which atoms to confirm, and which to undo; as participants are to atoms, so atoms are to cohesion composers (cohesions). The composer may prepare and cancel atoms at arbitrary points during the lifetime of the business transaction, e.g., preparing the flight reservation early in the transaction, and preparing the insurance quote much later after cancelling a prior quote. The main difference between an atom and a cohesion is that whereas all participants enrolled with an atom will either confirm or cancel, the participants enrolled with a cohesion (multiple atoms) may have different outcomes. However, once the composer has arrived at its confirm set (the participants that will confirm), it essentially collapses down to become an atom and guarantees an all-or-nothing effect, i.e., all atoms in the confirm set will either confirm or cancel, with no intermediate effects.

    Superiors and Inferiors
    Although for simplicity we've talked about services, coordinators, and participants, within BTP all end points are either Superiors or Inferiors or both. An actor within the coordinating entity's system plays the role of Superior (e.g., the atom coordinator) and an actor within the service plays the role of an Inferior (e.g., the participant). Each Inferior has only one Superior. However, a single Superior may have multiple Inferiors within single or multiple parties. A tree of such relationships may be wide, deep, or both, as shown in Figure 2.

     

    An Inferior is typically associated with some set of application activities. Usually this will be a result of some operation invocations (on a "service application element") from elsewhere (an "initiating application element"). The Inferior is responsible for reporting to the Superior that it is "prepared" for the outcome whether or not the associated operations' provisional effect can be confirmed or cancelled.

    A Superior receives reports from its Inferiors as to whether they are prepared to give an outcome. It gathers these reports in order to determine which Inferiors should be canceled and which confirmed. The Superior does this either by itself or with the cooperation of the application element responsible for its creation and control, depending upon whether the transaction is an atom or a cohesion, as we shall see later.

    The Initiator
    The initiator of the atom communicates with an atom/cohesion manager (factory) and asks it to start a new atom. Once created, information about the atom or cohesion (the context) can be propagated to Web services in order for them to associate their work with it. Although work is typically conducted within the scope of an atom, it is entirely possible for services to register participants directly with cohesions.

    The Terminator
    The terminator of the atom or cohesion will typically be the same entity as the initiator, but need not be. For example a long-running stock purchase transaction may be started by the company that requires the stock, and finished by the company that delivers it. Although an atom can be instructed to confirm all participants immediately, it is more typically instructed to prepare them first, and later (hours, days, etc.) to either confirm or cancel them.

    Summary
    BTP gives builders of transactional Web services the ability to concentrate on the functional aspects of their services (e.g., what it means to book an airline ticket), and to guarantee consensus through the participant interface. Since the participant interface is transparent to its implementation, a provider may use any implementation appropriate to the Web service it acts on behalf of.

    Through the cohesion composer, BTP gives the business logic the flexibility to structure interactions with services into multiple (dynamic) consensus groups. The important distinction between BTP and atomic transactions is that multiple such groups exist in BTP, compared to one in atomic transactions, and the cohesion has the capability to drive the two-phase termination protocol explicitly. The fact that atoms may be prepared at any point in the normal flow of business, and later confirmed or undone, gives greater flexibility to the application.

    Optimizations
    We have described how BTP can be used to conduct typical business-to-business interactions in a reliable manner. In order to do this, many protocol-specific messages need to be exchanged between actors, and this will have an adverse effect on the time taken to complete a business transaction. This is a necessary side effect of achieving reliability and consensus and is not specific to BTP.

    Since BTP is intended for long-running transactions, it may be assumed that performance hasn't been a prime factor in its development. However, this is not the case and, in fact, BTP contains a number of optimizations.

    One-Shot
    Typically a participant is enlisted with a BTP transaction when a service invocation occurs (e.g., "book flight"). When the service request completes, the response is sent back to the initiator of the request. As described earlier, during transaction termination the coordinator will interact with the participant to ensure completion.

    In some circumstances it may be possible to compound many of the above messages into a "one-shot" message. For example, the service invocation may cause a state change to occur that means the participant can prepare immediately after the invocation completes. Rather than having to wait for an explicit coordinator message, BTP allows the enroll request and statement of preparation to be compounded within the service response. The receiver is then responsible for ensuring that this additional information is forwarded to the responsible actors.

    Resignation by Participant
    In a two-phase commit protocol, in addition to indicating success or failure during the preparation phase, a participant can also return a "read-only" response; this indicates that it doesn't control any work that has been modified during the course of the transaction and therefore doesn't need to be informed of the transaction outcome. In some situations this allows the two-phase protocol to complete quickly, since a second round of messages isn't required.

    The equivalent of this in BTP is for a participant to resign from the transaction it was enrolled in. Resignation can occur at any time up to the point at which the participant has prepared. Resignation is used by the participant to indicate that it no longer has an interest in the outcome of the transaction.

    Spontaneous Prepare
    In some situations, rather than waiting for an instruction from the coordinator to prepare, a participant may be able to spontaneously prepare. For example, a service invocation occurs, moving the service into an idempotent state such that further invocations have no effect on it; in this case, an associated participant may prepare the service immediately, rather than wait for the instruction to do so. In BTP, a participant is allowed to attempt to prepare at any point and inform the coordinator of the result.

    Autonomous Decision by Participant
    In a traditional two-phase protocol a participant enrolls with a transaction and waits for the termination protocol before it either confirms or cancels. To achieve consensus, it is necessarily a blocking protocol, which means that if a coordinator fails before delivering the final phase messages, prepared participants must remain blocked, holding on to (possibly valuable) resources. Modern transaction-processing systems have augmented the two-phase commit with heuristics, which allow such participants to make unilateral decisions about whether they will commit or roll back. Obviously if a participant makes a choice that turns out to be different from that of other participants, nonatomic behavior occurs.

    BTP has its equivalent of heuristics, allowing participants to make unilateral decisions as well. However, unlike other transaction implementations, the protocol allows a participant to give the coordinator prior knowledge of what the decision will be and when it will occur. A participant may prepare and present the coordinator with some caveats as to how long it will remain in this state and into what state it will then migrate (e.g., "will remain prepared for 10 days and then will cancel the flight reservation"). This information may then be used by the coordinator to optimize message exchange.

    BTP and the Web Services Stack
    So where exactly does BTP fit into the evolving Web services architecture? As shown in Figure 3, it is primarily intended as a low-level protocol, hidden from users in much the same way traditional transaction systems are. Typically, a user would see just a demarcation API (e.g., how to start and end an atom); the BTP specification does not define any such API because it is language independent. One possible API that readers should be aware of is that being developed in JSR 156 - Java API for XML Transactions.

     

    So How Would I Use This BTP Thing?
    Consider the flight booking example presented earlier. How could we use BTP in order to coordinate this application in a reliable manner? The problem is that we wish to obtain the cheapest insurance quote as we go along, without losing prior quotes until we know that they are no longer the cheapest; at that point we will be able to release those quotes while maintaining others. In a traditional transaction system, all of the work performed within a transaction must either be accepted (committed) or declined (rolled back); the required loosening of atomicity is not supported.

    In BTP, however, we can use atoms and cohesions. A cohesion is first created to manage the overall business interactions. The business logic (application, client, etc.) creates an atom (i.e., ReserveAtom) and enrolls it with the cohesion, as shown in Figure 4.

     

    Once the client has obtained the context from the factory, it can invoke the airline and taxi reservation services within the scope of the atom, such that their work is then ultimately controlled by its outcome. When a suitable flight and taxi can be obtained, ReserveAtom is prepared to reserve the bookings for some service-specific time.

    Then two new atoms (AtomQuote1 and AtomQuote2) are created and enrolled with the cohesion, before being used to obtain two different quotes from the respective insurance services.

    When the quote from the first insurance site is obtained it is obviously not known whether it is the best quote, so the business logic can prepare AtomQuote1 to maintain the quote, while it then communicates with the second insurance site. If that site does not offer a better quote, the application can cancel AtomQuote2 and it now has its final confirmation set of atoms (ReserveAtom and AtomQuote1), which it can confirm (see Figure 5).

     

    Conclusions
    ACID transactions have proven invaluable over the years in the construction of enterprise applications. However, they are only really suited to short-duration activities executing on closely coupled applications and environments. When used in a loosely coupled environment, they prove too inflexible and restricting for many applications. The OASIS Business Transactions Protocol has been developed to solve this problem while at the same time maintaining those aspects of the atomic transaction model that have proven useful. At the time of this writing, there is only a single BTP implementation available, from Hewlett-Packard. However, several companies have stated that they are working on their own implementations.

    Resources

  • Business Transactions Protocol: www.oasis-open.org/committees/business-transactions
  • OMG CORBAservices: Common Object Services Specification: www.omg.org/oma
  • Java Transaction API 1.0.1 (JTA): http://java.sun.com/products/jta
  • XML Transactioning API for Java (JAXTX): www.jcp.org/jsr/detail/156.jsp
  • More Stories By Mark Little

    Mark Little was Chief Architect, Transactions for Arjuna Technologies Ltd, a UK-based company specialising in the development of reliable middleware that was recently acquired by JBoss, Inc. Before Arjuna, Mark was a Distinguished Engineer/Architect within HP Arjuna Labs in Newcastle upon Tyne, England, where he led the HP-TS and HP-WST teams, developing J2EE and Web services transactions products respectively. He is one of the primary authors of the OMG Activity Service specification and is on the expert group for the same work in J2EE (JSR 95). He is also the specification lead for JSR 156: Java API for XML Transactions. He's on the OTS Revision Task Force and the OASIS Business Transactions Protocol specification. Before joining HP he was for over 10 years a member of the Arjuna team within the University of Newcastle upon Tyne (where he continues to have a Visiting Fellowship). His research within the Arjuna team included replication and transactions support, which include the construction of an OTS/JTS compliant transaction processing system. Mark has published extensively in the Web Services Journal, Java Developer's Journal and other journals and magazines. He is also the co-author of several books including “Java and Transactions for Systems Professionals” and “The J2EE 1.4 Bible.”

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    @MicroservicesExpo Stories
    DevOps tends to focus on the relationship between Dev and Ops, putting an emphasis on the ops and application infrastructure. But that’s changing with microservices architectures. In her session at DevOps Summit, Lori MacVittie, Evangelist for F5 Networks, will focus on how microservices are changing the underlying architectures needed to scale, secure and deliver applications based on highly distributed (micro) services and why that means an expansion into “the network” for DevOps.
    Containers have changed the mind of IT in DevOps. They enable developers to work with dev, test, stage and production environments identically. Containers provide the right abstraction for microservices and many cloud platforms have integrated them into deployment pipelines. DevOps and Containers together help companies to achieve their business goals faster and more effectively. In his session at DevOps Summit, Ruslan Synytsky, CEO and Co-founder of Jelastic, reviewed the current landscape of...
    Conferences agendas. Event navigation. Specific tasks, like buying a house or getting a car loan. If you've installed an app for any of these things you've installed what's known as a "disposable mobile app" or DMA. Apps designed for a single use-case and with the expectation they'll be "thrown away" like brochures. Deleted until needed again. These apps are necessarily small, agile and highly volatile. Sometimes existing only for a short time - say to support an event like an election, the Wor...
    The cloud has transformed how we think about software quality. Instead of preventing failures, we must focus on automatic recovery from failure. In other words, resilience trumps traditional quality measures. Continuous delivery models further squeeze traditional notions of quality. Remember the venerable project management Iron Triangle? Among time, scope, and cost, you can only fix two or quality will suffer. Only in today's DevOps world, continuous testing, integration, and deployment upend...
    Discussions about cloud computing are evolving into discussions about enterprise IT in general. As enterprises increasingly migrate toward their own unique clouds, new issues such as the use of containers and microservices emerge to keep things interesting. In this Power Panel at 16th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the state of cloud computing today, and what enterprise IT professionals need to know about how the latest topics and trends affect t...
    Explosive growth in connected devices. Enormous amounts of data for collection and analysis. Critical use of data for split-second decision making and actionable information. All three are factors in making the Internet of Things a reality. Yet, any one factor would have an IT organization pondering its infrastructure strategy. How should your organization enhance its IT framework to enable an Internet of Things implementation? In his session at @ThingsExpo, James Kirkland, Red Hat's Chief Arch...
    Summer is finally here and it’s time for a DevOps summer vacation. From San Francisco to New York City, our top summer conferences list is going to continuously deliver you to the summer destinations of your dreams. These DevOps parties are hitting all the hottest summer trends with Microservices, Agile, Continuous Delivery, DevSecOps, and even Continuous Testing. Move over Kanye. These are the top 5 Summer DevOps Conferences of 2015.
    Sharding has become a popular means of achieving scalability in application architectures in which read/write data separation is not only possible, but desirable to achieve new heights of concurrency. The premise is that by splitting up read and write duties, it is possible to get better overall performance at the cost of a slight delay in consistency. That is, it takes a bit of time to replicate changes initiated by a "write" to the read-only master database. It's eventually consistent, and it'...
    "Plutora provides release and testing environment capabilities to the enterprise," explained Dalibor Siroky, Director and Co-founder of Plutora, in this SYS-CON.tv interview at @DevOpsSummit, held June 9-11, 2015, at the Javits Center in New York City.
    Containers are changing the security landscape for software development and deployment. As with any security solutions, security approaches that work for developers, operations personnel and security professionals is a requirement. In his session at DevOps Summit, Kevin Gilpin, CTO and Co-Founder of Conjur, will discuss various security considerations for container-based infrastructure and related DevOps workflows.
    Cloud Migration Management (CMM) refers to the best practices for planning and managing migration of IT systems from a legacy platform to a Cloud Provider through a combination professional services consulting and software tools. A Cloud migration project can be a relatively simple exercise, where applications are migrated ‘as is’, to gain benefits such as elastic capacity and utility pricing, but without making any changes to the application architecture, software development methods or busine...
    Data center models are changing. A variety of technical trends and business demands are forcing that change, most of them centered on the explosive growth of applications. That means, in turn, that the requirements for application delivery are changing. Certainly application delivery needs to be agile, not waterfall. It needs to deliver services in hours, not weeks or months. It needs to be more cost efficient. And more than anything else, it needs to be really, dc infra axisreally, super focus...
    The most often asked question post-DevOps introduction is: “How do I get started?” There’s plenty of information on why DevOps is valid and important, but many managers still struggle with simple basics for how to initiate a DevOps program in their business. They struggle with issues related to current organizational inertia, the lack of experience on Continuous Integration/Delivery, understanding where DevOps will affect revenue and budget, etc. In their session at DevOps Summit, JP Morgenthal...
    Overgrown applications have given way to modular applications, driven by the need to break larger problems into smaller problems. Similarly large monolithic development processes have been forced to be broken into smaller agile development cycles. Looking at trends in software development, microservices architectures meet the same demands. Additional benefits of microservices architectures are compartmentalization and a limited impact of service failure versus a complete software malfunction. ...
    Many people recognize DevOps as an enormous benefit – faster application deployment, automated toolchains, support of more granular updates, better cooperation across groups. However, less appreciated is the journey enterprise IT groups need to make to achieve this outcome. The plain fact is that established IT processes reflect a very different set of goals: stability, infrequent change, hands-on administration, and alignment with ITIL. So how does an enterprise IT organization implement change...
    While DevOps most critically and famously fosters collaboration, communication, and integration through cultural change, culture is more of an output than an input. In order to actively drive cultural evolution, organizations must make substantial organizational and process changes, and adopt new technologies, to encourage a DevOps culture. Moderated by Andi Mann, panelists discussed how to balance these three pillars of DevOps, where to focus attention (and resources), where organizations migh...
    At DevOps Summit NY there’s been a whole lot of talk about not just DevOps, but containers, IoT, and microservices. Sessions focused not just on the cultural shift needed to grow at scale with a DevOps approach, but also made sure to include the network ”plumbing” needed to ensure success as applications decompose into the microservice architectures enabling rapid growth and support for the Internet of (Every)Things.
    Mashape is bringing real-time analytics to microservices with the release of Mashape Analytics. First built internally to analyze the performance of more than 13,000 APIs served by the mashape.com marketplace, this new tool provides developers with robust visibility into their APIs and how they function within microservices. A purpose-built, open analytics platform designed specifically for APIs and microservices architectures, Mashape Analytics also lets developers and DevOps teams understand w...
    Buzzword alert: Microservices and IoT at a DevOps conference? What could possibly go wrong? In this Power Panel at DevOps Summit, moderated by Jason Bloomberg, the leading expert on architecting agility for the enterprise and president of Intellyx, panelists peeled away the buzz and discuss the important architectural principles behind implementing IoT solutions for the enterprise. As remote IoT devices and sensors become increasingly intelligent, they become part of our distributed cloud envir...
    Sumo Logic has announced comprehensive analytics capabilities for organizations embracing DevOps practices, microservices architectures and containers to build applications. As application architectures evolve toward microservices, containers continue to gain traction for providing the ideal environment to build, deploy and operate these applications across distributed systems. The volume and complexity of data generated by these environments make monitoring and troubleshooting an enormous chall...