Welcome!

Microservices Expo Authors: Elizabeth White, Aruna Ravichandran, Liz McMillan, Pat Romanski, Cameron Van Orman

Related Topics: Microservices Expo

Microservices Expo: 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
    Is advanced scheduling in Kubernetes achievable? Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, will answer these questions and demonstrate techniques for implementing advanced scheduling. For example, using spot instances ...
    We all know that end users experience the Internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices – not doing so will be a path to eventual b...
    Transforming cloud-based data into a reportable format can be a very expensive, time-intensive and complex operation. As a SaaS platform with more than 30 million global users, Cornerstone OnDemand’s challenge was to create a scalable solution that would improve the time it took customers to access their user data. Our Real-Time Data Warehouse (RTDW) process vastly reduced data time-to-availability from 24 hours to just 10 minutes. In his session at 21st Cloud Expo, Mark Goldin, Chief Technolo...
    Digital transformation leaders have poured tons of money and effort into coding in recent years. And with good reason. To succeed at digital, you must be able to write great code. You also have to build a strong Agile culture so your coding efforts tightly align with market signals and business outcomes. But if your investments in testing haven’t kept pace with your investments in coding, you’ll lose. But if your investments in testing haven’t kept pace with your investments in coding, you’ll...
    In his session at 21st Cloud Expo, Michael Burley, a Senior Business Development Executive in IT Services at NetApp, will describe how NetApp designed a three-year program of work to migrate 25PB of a major telco's enterprise data to a new STaaS platform, and then secured a long-term contract to manage and operate the platform. This significant program blended the best of NetApp’s solutions and services capabilities to enable this telco’s successful adoption of private cloud storage and launchi...
    Enterprises are adopting Kubernetes to accelerate the development and the delivery of cloud-native applications. However, sharing a Kubernetes cluster between members of the same team can be challenging. And, sharing clusters across multiple teams is even harder. Kubernetes offers several constructs to help implement segmentation and isolation. However, these primitives can be complex to understand and apply. As a result, it’s becoming common for enterprises to end up with several clusters. Thi...
    Containers are rapidly finding their way into enterprise data centers, but change is difficult. How do enterprises transform their architecture with technologies like containers without losing the reliable components of their current solutions? In his session at @DevOpsSummit at 21st Cloud Expo, Tony Campbell, Director, Educational Services at CoreOS, will explore the challenges organizations are facing today as they move to containers and go over how Kubernetes applications can deploy with lega...
    Today most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes significant work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reducti...
    DevOps at Cloud Expo, taking place October 31 - November 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA, is co-located with 21st Cloud Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to w...
    SYS-CON Events announced today that Cloud Academy has been named “Bronze Sponsor” of SYS-CON's 21st International Cloud Expo®, which will take place on Oct. 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Cloud Academy is the leading technology training platform for enterprise multi-cloud infrastructure. Cloud Academy is trusted by leading companies to deliver continuous learning solutions across Amazon Web Services, Microsoft Azure, Google Cloud Platform, and the most...
    The last two years has seen discussions about cloud computing evolve from the public / private / hybrid split to the reality that most enterprises will be creating a complex, multi-cloud strategy. Companies are wary of committing all of their resources to a single cloud, and instead are choosing to spread the risk – and the benefits – of cloud computing across multiple providers and internal infrastructures, as they follow their business needs. Will this approach be successful? How large is the ...
    DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
    Many organizations adopt DevOps to reduce cycle times and deliver software faster; some take on DevOps to drive higher quality and better end-user experience; others look to DevOps for a clearer line-of-sight to customers to drive better business impacts. In truth, these three foundations go together. In this power panel at @DevOpsSummit 21st Cloud Expo, moderated by DevOps Conference Co-Chair Andi Mann, industry experts will discuss how leading organizations build application success from all...
    DevSecOps – a trend around transformation in process, people and technology – is about breaking down silos and waste along the software development lifecycle and using agile methodologies, automation and insights to help get apps to market faster. This leads to higher quality apps, greater trust in organizations, less organizational friction, and ultimately a five-star customer experience. These apps are the new competitive currency in this digital economy and they’re powered by data. Without ...
    A common misconception about the cloud is that one size fits all. Companies expecting to run all of their operations using one cloud solution or service must realize that doing so is akin to forcing the totality of their business functionality into a straightjacket. Unlocking the full potential of the cloud means embracing the multi-cloud future where businesses use their own cloud, and/or clouds from different vendors, to support separate functions or product groups. There is no single cloud so...
    For most organizations, the move to hybrid cloud is now a question of when, not if. Fully 82% of enterprises plan to have a hybrid cloud strategy this year, according to Infoholic Research. The worldwide hybrid cloud computing market is expected to grow about 34% annually over the next five years, reaching $241.13 billion by 2022. Companies are embracing hybrid cloud because of the many advantages it offers compared to relying on a single provider for all of their cloud needs. Hybrid offers bala...
    With the modern notion of digital transformation, enterprises are chipping away at the fundamental organizational and operational structures that have been with us since the nineteenth century or earlier. One remarkable casualty: the business process. Business processes have become so ingrained in how we envision large organizations operating and the roles people play within them that relegating them to the scrap heap is almost unimaginable, and unquestionably transformative. In the Digital ...
    These days, APIs have become an integral part of the digital transformation journey for all enterprises. Every digital innovation story is connected to APIs . But have you ever pondered over to know what are the source of these APIs? Let me explain - APIs sources can be varied, internal or external, solving different purposes, but mostly categorized into the following two categories. Data lakes is a term used to represent disconnected but relevant data that are used by various business units wit...
    The nature of the technology business is forward-thinking. It focuses on the future and what’s coming next. Innovations and creativity in our world of software development strive to improve the status quo and increase customer satisfaction through speed and increased connectivity. Yet, while it's exciting to see enterprises embrace new ways of thinking and advance their processes with cutting edge technology, it rarely happens rapidly or even simultaneously across all industries.
    It has never been a better time to be a developer! Thanks to cloud computing, deploying our applications is much easier than it used to be. How we deploy our apps continues to evolve thanks to cloud hosting, Platform-as-a-Service (PaaS), and now Function-as-a-Service. FaaS is the concept of serverless computing via serverless architectures. Software developers can leverage this to deploy an individual "function", action, or piece of business logic. They are expected to start within milliseconds...