Welcome!

Microservices Expo Authors: Pat Romanski, Liz McMillan, Elizabeth White, Mamoon Yunus, Jason Bloomberg

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
    Did you know that you can develop for mainframes in Java? Or that the testing and deployment can be automated across mobile to mainframe? In his session and demo at @DevOpsSummit at 21st Cloud Expo, Dana Boudreau, a Senior Director at CA Technologies, will discuss how increasingly teams are developing with agile methodologies, using modern development environments, and automating testing and deployments, mobile to mainframe.
    As DevOps methodologies expand their reach across the enterprise, organizations face the daunting challenge of adapting related cloud strategies to ensure optimal alignment, from managing complexity to ensuring proper governance. How can culture, automation, legacy apps and even budget be reexamined to enable this ongoing shift within the modern software factory?
    While some vendors scramble to create and sell you a fancy solution for monitoring your spanking new Amazon Lambdas, hear how you can do it on the cheap using just built-in Java APIs yourself. By exploiting a little-known fact that Lambdas aren’t exactly single-threaded, you can effectively identify hot spots in your serverless code. In his session at @DevOpsSummit at 21st Cloud Expo, Dave Martin, Product owner at CA Technologies, will give a live demonstration and code walkthrough, showing how ...
    API Security is complex! Vendors like Forum Systems, IBM, CA and Axway have invested almost 2 decades of engineering effort and significant capital in building API Security stacks to lockdown APIs. The API Security stack diagram shown below is a building block for rapidly locking down APIs. The four fundamental pillars of API Security - SSL, Identity, Content Validation and deployment architecture - are discussed in detail below.
    @DevOpsSummit at Cloud Expo taking place Oct 31 - Nov 2, 2017, at the Santa Clara Convention Center, Santa Clara, CA, is co-located with the 21st International 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 ...
    We define Hybrid IT as a management approach in which organizations create a workload-centric and value-driven integrated technology stack that may include legacy infrastructure, web-scale architectures, private cloud implementations along with public cloud platforms ranging from Infrastructure-as-a-Service to Software-as-a-Service.
    There are several reasons why businesses migrate their operations to the cloud. Scalability and price are among the most important factors determining this transition. Unlike legacy systems, cloud based businesses can scale on demand. The database and applications in the cloud are not rendered simply from one server located in your headquarters, but is instead distributed across several servers across the world. Such CDNs also bring about greater control in times of uncertainty. A database hack ...
    In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
    Docker is on a roll. In the last few years, this container management service has become immensely popular in development, especially given the great fit with agile-based projects and continuous delivery. In this article, I want to take a brief look at how you can use Docker to accelerate and streamline the software development lifecycle (SDLC) process.
    In his session at 20th Cloud Expo, Chris Carter, CEO of Approyo, discussed the basic set up and solution for an SAP solution in the cloud and what it means to the viability of your company. Chris Carter is CEO of Approyo. He works with business around the globe, to assist them in their journey to the usage of Big Data in the forms of Hadoop (Cloudera and Hortonwork's) and SAP HANA. At Approyo, we support firms who are looking for knowledge to grow through current business process, where even 1%...
    With Cloud Foundry you can easily deploy and use apps utilizing websocket technology, but not everybody realizes that scaling them out is not that trivial. In his session at 21st Cloud Expo, Roman Swoszowski, CTO and VP, Cloud Foundry Services, at Grape Up, will show you an example of how to deal with this issue. He will demonstrate a cloud-native Spring Boot app running in Cloud Foundry and communicating with clients over websocket protocol that can be easily scaled horizontally and coordinate...
    IT organizations are moving to the cloud in hopes to approve efficiency, increase agility and save money. Migrating workloads might seem like a simple task, but what many businesses don’t realize is that application migration criteria differs across organizations, making it difficult for architects to arrive at an accurate TCO number. In his session at 21st Cloud Expo, Joe Kinsella, CTO of CloudHealth Technologies, will offer a systematic approach to understanding the TCO of a cloud application...
    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...
    API Security has finally entered our security zeitgeist. OWASP Top 10 2017 - RC1 recognized API Security as a first class citizen by adding it as number 10, or A-10 on its list of web application vulnerabilities. We believe this is just the start. The attack surface area offered by API is orders or magnitude larger than any other attack surface area. Consider the fact the APIs expose cloud services, internal databases, application and even legacy mainframes over the internet. What could go wrong...
    Cloud adoption is often driven by a desire to increase efficiency, boost agility and save money. All too often, however, the reality involves unpredictable cost spikes and lack of oversight due to resource limitations. In his session at 20th Cloud Expo, Joe Kinsella, CTO and Founder of CloudHealth Technologies, tackled the question: “How do you build a fully optimized cloud?” He will examine: Why TCO is critical to achieving cloud success – and why attendees should be thinking holistically ab...
    The goal of Continuous Testing is to shift testing left to find defects earlier and release software faster. This can be achieved by integrating a set of open source functional and performance testing tools in the early stages of your software delivery lifecycle. There is one process that binds all application delivery stages together into one well-orchestrated machine: Continuous Testing. Continuous Testing is the conveyer belt between the Software Factory and production stages. Artifacts are m...
    Web services have taken the development world by storm, especially in recent years as they've become more and more widely adopted. There are naturally many reasons for this, but first, let's understand what exactly a web service is. The World Wide Web Consortium (W3C) defines "web of services" as "message-based design frequently found on the Web and in enterprise software". Basically, a web service is a method of sending a message between two devices through a network. In practical terms, this ...
    In his session at @DevOpsSummit at 20th Cloud Expo, Kelly Looney, director of DevOps consulting for Skytap, showed how an incremental approach to introducing containers into complex, distributed applications results in modernization with less risk and more reward. He also shared the story of how Skytap used Docker to get out of the business of managing infrastructure, and into the business of delivering innovation and business value. Attendees learned how up-front planning allows for a clean sep...
    In IT, we sometimes coin terms for things before we know exactly what they are and how they’ll be used. The resulting terms may capture a common set of aspirations and goals – as “cloud” did broadly for on-demand, self-service, and flexible computing. But such a term can also lump together diverse and even competing practices, technologies, and priorities to the point where important distinctions are glossed over and lost.
    "At the keynote this morning we spoke about the value proposition of Nutanix, of having a DevOps culture and a mindset, and the business outcomes of achieving agility and scale, which everybody here is trying to accomplish," noted Mark Lavi, DevOps Solution Architect at Nutanix, in this SYS-CON.tv interview at @DevOpsSummit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.