WO2009079258A2 - Procédé et système pour développer des applications transactionnelles à l'aide d'un environnement de développement intégré, comprenant une bibliothèque de services pour s'assurer qu'une application de traitement de transaction est entièrement transactionnelle - Google Patents

Procédé et système pour développer des applications transactionnelles à l'aide d'un environnement de développement intégré, comprenant une bibliothèque de services pour s'assurer qu'une application de traitement de transaction est entièrement transactionnelle Download PDF

Info

Publication number
WO2009079258A2
WO2009079258A2 PCT/US2008/085874 US2008085874W WO2009079258A2 WO 2009079258 A2 WO2009079258 A2 WO 2009079258A2 US 2008085874 W US2008085874 W US 2008085874W WO 2009079258 A2 WO2009079258 A2 WO 2009079258A2
Authority
WO
WIPO (PCT)
Prior art keywords
transaction processing
processing application
service adaptors
message
methodology
Prior art date
Application number
PCT/US2008/085874
Other languages
English (en)
Other versions
WO2009079258A3 (fr
Inventor
Daniel J. Sifter
Jonathon C. Pile
Joseph S. Fontaine
Mark Phillips
Original Assignee
Kabira Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/959,345 external-priority patent/US20090158242A1/en
Priority claimed from US11/959,333 external-priority patent/US20090158246A1/en
Application filed by Kabira Technologies, Inc. filed Critical Kabira Technologies, Inc.
Publication of WO2009079258A2 publication Critical patent/WO2009079258A2/fr
Publication of WO2009079258A3 publication Critical patent/WO2009079258A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the number of services has grown from a simple voice call to text messaging, internet access, video, real-time data and special purpose e-commerce functions.
  • the approval to use a service should be granted in real-time.
  • revenue and business model the revenue-per- transaction may typically be measured in cents or even micro-cents, and business models and service offerings change frequently.
  • SOA-based solutions are delivered as sets of services that can be combined and recombined to meet new requirements.
  • EDA event-driven architecture
  • solutions are increasingly automated, bringing in human intervention only when an exception arises that is beyond the scope of an automated solution.
  • EAI Enterprise Application Integration
  • a transaction processing development methodology employs a transaction processing development framework to facilitate development of a desired transaction processing application.
  • a plurality of service adaptors are provided.
  • An infrastructure is provided via which a user defined business logic of the desired transaction processing application may be provided to the transaction processing development framework.
  • the business logic definition is processed to instantiate the transaction processing application, including, instantiating a subset of the service adaptors to implement services of the transaction processing application, and further including arranging the instantiated service adaptors to accomplish the business logic in conjunction with generic transaction processing logic.
  • the arrangement of service adaptors is guaranteed, when executed, to accomplish the transaction processing application in a manner that is fully transactional.
  • the service adaptors may be from a library of service adaptors is provided.
  • At least a first portion of the service adaptors are generically applicable to transaction processing applications that are fully transactional and at least a second portion of the service adaptors are specifically applicable to transaction processing applications in a particular business area.
  • a user-defined business logic of the desired transaction processing application is processed to instantiate the transaction processing application, including instantiating service adaptors from the first portion of the service adaptors and from the second portion of the service adaptors, to implement services of the transaction processing application.
  • the instantiated service adaptors are arranged to guarantee such that, when executed, the transaction processing application is accomplished in a manner that is fully transactional.
  • FIG. 1 provides a general illustration of parts of an example processing engine, which may be considered the fundamental unit of deployment of a transaction processing platform.
  • Fig. 2 illustrates an example of a high-speed channel adaptor framework.
  • Fig. 3 illustrates nodes as a collection of processing engines working together on one area of shared memory, which plays the role of a database.
  • Fig. 4 illustrates messages being spread across the nodes by a special processing engine called a distribution engine
  • Fig. 5 schematically illustrates an example of a solution architecture.
  • Fig. 6 illustrates, from a different point of view, how a message may move through the transaction processing platform.
  • Fig. 7 illustrates an example of more detail of a message mapping by message mapper logic.
  • FIG. 8 schematically illustrates a multi-node deployment of business process components of a transaction processing platform, such as the business process components of Fig. 6.
  • Fig. 9 provides more detail of an example of runtime services of the transaction processing platform.
  • Fig. 10 illustrates a specific example configuration of services of the transaction processing platform, to handle an electronic payment authorization request, such as a transaction in which a credit card has been presented for payment.
  • Fig. 11 is a sequence diagram showing a simple request/response pattern with no use of message correlation, where the response contains enough information to perform route selection to return the message to the request flow.
  • Fig. 12 is a sequence diagram showing a simple request/response pattern with message correlation used, where the response does not contain enough information to perform route selection to return the message to the request flow.
  • Fig. 13 is a taxonomy-type description where the end-user is at the top of the diagram, building a set of configurations to combine everything into a transaction processing application.
  • Figs. 14-16 each show a simplified view of a typical deployment of a transaction processing solution and illustrate various routing scenarios.
  • Fig. 17 illustrates a system implemented by many individual flows - request, response, timeout, and error flows.
  • Fig. 18 illustrates a classification flow.
  • Fig. 19 illustrates a typical configuration of a flow, in this case, an authorization request flow.
  • Fig. 20 illustrates a typical configuration of an authorization response flow.
  • FIG.21 schematically illustrates an example of the development methodology and environment.
  • Fig. 22 shows the implementation of Fig. 21 in greater detail.
  • Fig. 23 illustrates an example of an integrated development environment (IDE) display.
  • IDE integrated development environment
  • Fig. 24 illustrates an example of the canvas portion of the Fig. 23 example display in greater detail.
  • the inventors have proposed an architecture that will provide the data access speed of an in-memory database, the flexible logic of an application server, the highspeed transport and dynamic routing of EAI middleware, the transaction processing speed of specialized systems and the resilience and fault tolerance of high- availability hardware.
  • a transaction processing platform is provided that is suitable for model- driven development. In this way, the complexity of high performance computing is addressed. Building a solution on such a transaction processing platform lets programmers create a model in a standard environment (such as that provided by Eclipse - see www.eclipse.org), using an "action language" to specify detailed logic including combining logic of standard services on top of a standard infrastructure. The model specifies what the system will do by describing objects and their relationships. Once the model is created, the transaction processing platform compiles that model into a transaction processing business solution. [0034] Furthermore, for example, the solution may be optimized at every level, combining various subsystems for data management, process management, integration and configuration, and providing other key transactional services for transaction processing.
  • the transaction processing platform in one example, is engineered to enable businesses to more easily offer a stream of evolving high-quality services in the marketplace, at a fraction of the cost of the alternatives.
  • the architecture of the transaction processing platform establishes a fundamental set of capabilities and services that can be reused and combined in different ways to create flexible, high-performance solutions.
  • the work of solutions developed for the transaction processing platform may be performed by the following elements: • infrastructure system: the part of the platform focused on data management and transactions
  • reaction switch the part of the platform focused on process and flow management 'channels: a high-speed adapter framework to data into the platform from external sources and to send and receive data out of the platform, such as through a stream of messages
  • • configuration management the part of the platform that provides an abstraction of the system landscape
  • operations management the part of the platform that monitors real-time operations and allows a solution to be dynamically reconfigured
  • •transactional services specialized elements such as deadlock detection, mirroring, caching, pooling, transactional replication, memory management and routing functionality used to create high-performance transaction processing systems.
  • Fig. 1 provides a general idea of how these parts may fit together into an example processing engine, which may be considered the fundamental unit of deployment.
  • the configuration layer and operational management layers do similar jobs as the same layers in other software, providing ways to allow the process to be useful for different situations by changing configurations. Some details of both of these layers will be discussed later.
  • Fig. 2 illustrates an example of a high-speed channel adaptor framework.
  • the high-speed channel adapter framework is configured to move data in and out of the transaction switch and infrastructure system.
  • all data in the transaction switch and infrastructure system layers is stored in shared memory, and is normalized to a standard format. All of the logic and processing that converts data to and from this standard format may be localized to the channel adapters, which can ensure that the application will not have to be modified to function with a new (or newer version) of a communication protocol, for example.
  • a channel adaptor for that protocol would be utilized to function with the communication protocol.
  • channel adapters are modeled, rather than coded, using traditional programming languages. This allows the compiler to analyze and optimize the data transformations that take place in the adapters.
  • the transaction switch layer is a real-time application server focused on process management.
  • an application is modeled using Eclipse, for example, a series of objects is created and the behavior of the objects and the interactions between the objects are described in the model.
  • To automate a business process information flows from one object to another and the state of the process is maintained.
  • the process flows in a model are analyzed to determine which parts of the process are parallel and which are serial.
  • the transaction switch layer performs this analysis and then provides all the "plumbing" to synchronize parallel execution when possible.
  • the infrastructure layer can be thought of as a real-time application server focused on data management and transactions. When thousands of transactions per second are streaming through the engines in a node, the shared memory acts as a database. Each engine is running multiple threads and each engine is a separate, multi-threaded process; access to the data is strictly controlled to keep the data consistent. It is also desired, however, that all processing proceed as quickly as possible.
  • the infrastructure layer provides the locking, event procession, data replication, and synchronization mechanisms used to turn shared memory into a highspeed repository for transaction processing. Transactional services include utility functionality for the high-speed transaction processing platform, such as real-time loading of components in engines, to error reporting. [0039] Solutions built on the transaction processing platform architecture may feature the following structure:
  • Engines communicate to the outside world using channel adapters that send and receive messages, process data using components, and store and retrieve data from shared memory. Each engine is multi-threaded and runs in its own process (such as a UNIX process). • Configuration information is used by an engine to determine sources and destinations for messages.
  • Nodes are a collection of engines working together on one area of shared memory, which plays the role of a database (as shown in Fig. 3). Any number of engines, each playing similar or different roles, can be part of a node.
  • the channel adaptor framework may be thought of as the integration workhorse of the transaction processing platform. Like many transaction platforms, information passes to and from the engine in the form of messages. Even when external APIs are used to gather information from databases or special purpose external systems, the information gathered can be considered a stream of messages.
  • the channels are adapters built using the framework. Channels move data to and from databases and external systems of record, Web services provided by other applications, and message queues from EAI systems at very high speeds and other appropriate sources/destinations.
  • the channel adapter framework transforms external messages into a normalized information format used by the transaction processing platform. Modeling may be used for everything, including the construction of the channel adapters, unlike other adapter frameworks that are based on coding in languages like Java or C++.
  • Models used to define solutions can be compiled to run on popular flavors of UNIX, for example.
  • the transaction processing platform may be designed to scale on both a single platform and across multiple platforms. Thus, it may be chosen to deploy the transaction processing platform on a system that fits desired processing needs: applications hosted on the transaction processing platform can be deployed on large multiprocessor machines or on many smaller machines to meet application performance requirements. Less processor-intensive or memory-intensive nodes can be deployed on low-cost hardware running Linux, for example, while nodes using the more powerful processors and large memory spaces can run naturally on the most powerful hardware. [0043] Another way that the transaction processing platform can be used to handle rapid growth in transaction volume is to scale "up" linearly with CPUs and clock speed.
  • the transaction processing platform may be designed to take advantage of the CPU, memory and disk resources available on its host platform. As CPUs, threads, real memory and disk space increase, the runtime may scale transparently to the application.
  • CPU scaling may be achieved through the use of operating system-level threading.
  • the total number of threads used may be optimized to minimize "empty CPU cycles" caused by excessive thread context switching, thus ensuring that CPUs are kept busy performing application work, not as much on operating system housekeeping.
  • the architecture does not just "throw threads at the problem" to simplify the implementation.
  • the transaction processing platform in some examples does not perform global locking. Locking of shared resources may be designed to minimize lock contention. This may be accomplished by minimizing or eliminating global resources that must be locked by all threads before any work can be performed.
  • This vertical scalability power may be derived by consolidating data, event and logic processing into a shared memory, and the kernel-threaded event execution architecture, which gives the transaction processing platform the power to take maximum advantage of the computers on which it runs.
  • a solution can utilize as much memory as will ever be available on a computer. Placing all of the data in memory can enable incredibly fast processing.
  • Such unique linear vertical scalability can allow applications to scale from Proof-of-Concept to full-scale production without performance re-engineering.
  • Application scaling can also occur in another way, as the architecture can be scaled "out" horizontally with the introduction of additional servers.
  • the node architecture allows as many nodes as needed to run on as many computers as desired.
  • the message traffic may be spread across the nodes by a special engine called a distribution engine (as shown in Fig. 4).
  • a distribution engine operates to allow messages to be spread across other nodes that are running on the same computer or different computers in many different ways. For example, for a given stock-trading application, all of the ticker symbols from A to K could be on one node and the tickers from L to Z could be on another.
  • the ability to perform dynamic configuration via a "High Availability Component" may improve the situation even further. For example, in a stock transaction processing system, if a particular stock is trading heavily, it is possible to route traffic just for that ticker to another node to better balance the load. Such rerouting can take place on the fly with, for example, no downtime.
  • HA Component may give an enterprise business system "five 9s"
  • the transaction processing platform utilizes transactional replication and mirroring functions to accomplish high availability of data.
  • the platform guarantees data integrity by routing each transaction to an active copy of the data. Key stateful objects can be tagged to be highly available so that in the event of a transaction failure, the High Availability Component's Message Router forces a switchover to a designated backup server, which then becomes active and assumes responsibility for completing transactions until the primary server is restored. The system continues to process every transaction in real-time, and failover is transparent to users.
  • Object partitions in the HA Component assure data integrity by having a single master copy of each instance and by avoiding distributed locks.
  • the transactional part of the replication ensures that the write on the primary system is not considered complete until the replication is complete. Any node can play the role of a primary node, a backup node, or both at the same time.
  • the transaction processing platform also features a variety of high- availability mechanisms such as the ability to queue bursts of transactions during high- volume periods and the ability to re -process transactions that fail in the middle of a transaction.
  • the high-availability feature protects both data and applications. When the High Availability Component is enabled, HA and recovery logic are inherent in every application built on the transaction processing platform, providing transparent application recovery support and saving costly IT resources and time, since programmers need not write HA-aware code into each application.
  • the memory-resident transactions and processing ensure memory-speed recovery from failure. Moreover, high-speed rollback and recovery occurs not only for all data associated with an application, but also the current processing state at time of failure; thus, applications may restart from the last successful processing step.
  • the transaction processing platform in one aspect, also features a powerful and flexible Security Component that ensures the confidentiality, integrity and security of all data and mission-critical applications deployed on the platform.
  • Security-enabled systems perform with very high speed and efficiency because users enable security only for those operations desired to be secured — there is no performance impact to operations not desired to be secured. Endowing any application with security can be as simple as turning on the Security Component - no coding required.
  • the Security Component provides users with fine-grained control over rules of access, allows security functionality to be added retroactively to previously unsecured applications, and provides support for existing security technologies (such as via the Security Services Layer — SSL).
  • the transaction processing platform is flexible enough to handle the real world challenges of high- volume transaction processing.
  • the transaction processing platform offers platform independence, for example, supporting Solaris, and Linux.
  • New components can be loaded into an engine while the rest of the engine continues running. The new component can go live with virtually no impact on an operating system, allowing bug fixes or new versions to come into production without scheduled downtime.
  • the configuration mechanisms are similarly flexible. When an engine is loaded, the engine looks for configuration information that describes the location of other nodes to communicate with, and for external services that will be used. Configuration information can be changed on the fly. Failsafe mechanisms exist to prevent shutting down a connection to a node while the other node is still active. Configuring for High Availability, such as determining which node is going to handle which messages, is also configurable at runtime.
  • Uncontrolled system changes are a frequent cause of system outages.
  • An organization should be able to build, test and deploy new versions of mission-critical applications as often as necessary — while relying on continuous systems and transaction operations.
  • Change management functions of the transaction processing platform ensure system stability during major system changes, including during system configuration changes and when adding or deleting hardware devices from the running system.
  • a number of reconfiguration tasks can also be controlled at the application level in order to maintain, repair or upgrade elements of a system without needing to shut down or restart.
  • Fig. 5 schematically illustrates an example of a solution architecture.
  • Service Components are special purpose collections of components, engines, and nodes that are dedicated to executing a particular function - specific needs for a line of business.
  • a payment component may be configured to provide functionality to process electronic payments.
  • Solutions are enterprise software products built using the transaction processing platform. Pre-packaged solutions may be provided for payment processing, for telecommunications provisioning, and other business areas. While prepackaged solutions are built using the model-driven technique, the pre-packaged solutions are nonetheless configurable solutions like any other enterprise software. Modeling can be used to extend the functionality of a pre-packaged solution.
  • the transaction processing platform interacts with data from systems of record containing customer or account information. The transaction processing platform is not merely a high-performance cache, using messaging and a memory-resident database. Rather, with the Channel Adapter Framework and the mechanism for transactionally storing data in various repositories, the transaction processing platform can operate as systems of record and manage important information.
  • the transaction processing platform can interact with data in other systems in the following scenarios.
  • the transaction processing platform may be a system of record, using a persistent storage mechanism, such as a database, as a permanent repository. Any other systems that need the stored data can ask for it through message-based transactions or applications built on the transaction processing platform.
  • the data in the permanent repository can also be replicated to any other repositories that may need to use the data on a read-only basis.
  • the transaction processing platform may be a high- performance cache.
  • the system of record may be the "master" and the transaction processing platform loads data from the system of record when the system is started. Then, as transactions are processed, the transaction processing platform operates to send a stream of updates back to the system of record.
  • the transaction processing platform may be a hybrid.
  • the transaction processing system combines aspects of both a high- performance cache and a system of record.
  • master data (which changes much less frequently than transactional data)
  • the transaction processing system may play the role of a cache and bring master data in at startup time, not updating the master data until the system is restarted or the data is scheduled for a refresh.
  • Transactional data particularly if being assembled from many different underlying systems, could be managed inside the transaction processing system as a system of record. Changes to the transactional data could then be distributed to the source systems in a variety of ways.
  • a methodology for creating solutions delivers on the full promise of model-driven development.
  • Most other development environments or products that use model-driven development offer a partial solution, presenting a visual interface for some portions of an application, even though the objects that the model is gluing together must be developed in a traditional programming language, such as Java or C++.
  • a traditional programming language such as Java or C++.
  • partially modeled applications can improve productivity in some situations, the approach may be inadequate for high-performance computing.
  • a fully modeled solution one in which all the objects and their behavior are expressed in a modeling language - a whole new world of optimization and automatic assembly of components is opened up.
  • the transaction processing system has a view of the entire application and can then render an implementation of that model using its understanding of threads to take advantage of parallelism and apply all of the transactional services where needed.
  • a result of the model-driven development may be reduction in development and implementation complexity and an increase in application quality.
  • the power of modeling has tremendous leverage. For example, 20,000 lines of a model may result in generation of the equivalent of 2 million lines of implementation code. Models are much easier to maintain than thousands of lines of code and are less prone to error.
  • a model creation environment such as Eclipse provides a visual representation of the models used to create engines in the transaction processing platform.
  • a Model- Driven Architecture (MDA) may be employed, which allows applications to be specified using a modeling language like UML or BPEL and the implementation of the application can then be generated. The model is compiled into an executable engine.
  • MDA Model- Driven Architecture
  • the model-driven architecture enables programmers to develop and deploy new services and network-based applications using high-level UML models, standard action language and automatically-generated Web Services, CORBA, Java or XML interfaces that are independent of underlying technology. This allows system architects to design very complex solutions in a few weeks or months, with a small team of modeling and domain experts.
  • a convenient feature of examples of the transaction processing platform includes separation of configuration information from applications.
  • the system can be configured using, for example, XML instructions, without the need for programming.
  • the switch can also be dynamically reconfigured while the system is running to allow for new business rules and multiple versions of business rules.
  • Configuration files can be versioned.
  • One version for example, could describe the testing environment, another could describe the staging environment, and still another could describe the production environment. Certain changes may be refused, such as closing a connection from one side when the other side of the connection is still open.
  • the model can be used to generate initial test cases.
  • the end-point simulation and testing framework allows for the creation of proxies for external services to simulate their behavior.
  • the testing framework also contains a mechanism for storing test data. Using this framework, the functional accuracy can be tested using pass/fail tests.
  • the performance of the application can be analyzed under load.
  • the performance testing features of the platform allow statistics to be gathered to assist in optimizing the model.
  • the transaction processing platform in some examples, is highly configurable at run-time. Configuration changes, loading of new components and tuning of high- availability features can all take place during transaction processing without interruption. [0077] In a hardware-based high-availability system, every part of an application runs on expensive, high-performance hardware.
  • Each node runs on one machine.
  • the powerful platform node architecture can run on commodity hardware, giving a choice of determining where to place nodes, based on the type of hardware each node may use to achieve optimum performance.
  • the size and expense of the hardware allocated to each node can be tuned so that each node gets the CPU and memory it needs at the lowest possible cost. For example, nodes that do not need such high performance hardware may run on lower-cost Linux-based systems.
  • Fig. 5 illustrates an example operation of a particular implementation of a transaction processing platform - in this case, for payment processing.
  • data arrives from the network on a channel 502 and is passed to a channel adaptor 504.
  • the channel adaptor 504 converts data from the channel into a normalized format for processing by the processes of the transaction processing platform.
  • the channel adaptor also operates according to a communication protocol or protocols by which the data is transmitted on the network.
  • Reference numeral 506 indicates the message in the normalized format being provided for processing.
  • a classifier business flow 508 is provided, to determine a particular processing path based on a classification of the message 506.
  • the determined processing path may be, for example, one of business process 2 (510a), business process 3 (510b) and business process 4 (510c).
  • the determined processing path is business process 3 (510b).
  • the processes access accelerator services service components 512.
  • a routing service component 514 is consulted, and a resulting output message 516 (in normalized format) is provided to a channel adaptor 518.
  • the channel adaptor 518 handles adjusting the format of the output message 516 and also operates according to a communication protocol or protocols by which the data is transmitted on the network from the channel 520.
  • Fig. 6 illustrates, from a different point of view, how a message may move through the transaction processing platform.
  • a channel adaptor 601 operates to input a protocol data unit 602 in a wire format 603, according to a network protocol A.
  • the protocol data unit 602 is transformed into a structured data unit 604, including parsing data 606 from the protocol data unit 602.
  • the channel adaptor 601 also includes validation mapping.
  • the structured data unit 604 is provided by the channel adaptor 601 to business process components 610.
  • the business process components 610 operate on normalized application level data 612 of the structured data unit 604.
  • the business process components 610 operate to implement business logic 614 with respect to the normalized application level data 612.
  • the business process components 610 operate in conjunction with message mapper logic 616 of a channel adaptor 618 to transform an output structured data unit 620 of the business process components 610 into a protocol data unit 622 for output by the channel adaptor 618 according to network protocol B.
  • message mapper logic 616 operates to, in one example, map between an internal, normalized, message format and a structured data unit format expected by a system with which the transaction platform is interacting.
  • the integrated development environment operates to write a "mapping file" when a message mapping is saved.
  • the message mapping for a particular message may be, for example, embodied in a "mapping file" containing the properties of the mapping and a list of rules for performing the mapping, including checking for errors.
  • the mapping file is processed into executable code to perform the specified mapping.
  • Fig. 8 schematically illustrates a multi-node deployment of business process components of a transaction processing platform, such as the business process components 610 shown in Fig. 6, for example.
  • the nodes of a multi-node deployment may participate in active/active or active/standby modes to provide application-level fail-over services.
  • Fig. 9 provides more detail of an example of runtime services of the transaction processing platform
  • Fig. 10 illustrates a specific example configuration of services of the transaction processing platform, to handle an electronic payment authorization request, such as a transaction in which a credit card has been presented for payment.
  • Routing is the act of moving a message between a source and a destination using a route.
  • a source is the origination of a message; the destination is the logical target of the message.
  • the physical destination for a message is usually at least a network hop away from the route destination.
  • the source and destination of a message can be on the same or different transaction processing platform nodes.
  • a route may be uniquely identified by a name, and a collection of routes defines a route table. There can be multiple named route tables.
  • Normalized messages are sent over a path once a route has been selected by the application. There can be multiple paths defined for a route. The path used may be based on path selection criteria and metrics. Path selection is performed by the routing component, as opposed to route selection, which is performed by the application. A destination address uniquely identifies a path within a route. [0089] In one example, supported addresses are:
  • Paths may be chosen based on a path selection policy and the availability of paths. For example, preference may be given to local paths, path priorities, and finally, selection within the same path priorities. If a higher priority path is not available, a lower priority path may be used. This means that path selection criteria may be locality and priority with the path metric being availability. [0091] Other possible path selection criteria may include:
  • the routing service provides all of the services to deliver the message to the destination.
  • the destination could be on the same node or on a different node in the network. This distinction is generally transparent to the application.
  • a single destination can be associated with multiple routes. This is useful, for example, to allow:
  • the routing service does not support store-and- forward routing, meaning that all routing is done point-to-point between nodes. That is, in such an example, all routing is static, or source routing, with no support for dynamic, or destination routing (such as is used on the internet). In other examples, dynamic, destination routing may be employed.
  • Inactive - route or path has no connectivity and cannot transmit messages Only enabled routes or paths can be active. Disabled routes and paths are always inactive.
  • Request message does not contain enough information to route message back to requestor.
  • Request/response message correlation is used to determine how to route the response back to the requestor.
  • the sequence diagram in Fig. 11 shows a simple request/response pattern with no use of message correlation, where the response contains enough information to perform route selection to return the message to the request flow.
  • the following steps are taken in this sequence diagram: a) A consumer in a request flow selects a request route to send a request to a destination endpoint. b) The routing component delivers the request to the destination endpoint using the request route. c) The destination endpoint sends the request over the network to an external system. d) The external system responds to the request on the same endpoint. e) The endpoint delivers the response to the response route selector flow.
  • a consumer in the response route selector flow uses data in the response to select the response route to return the response to the originating request flow
  • the routing component delivers the response to the destination request flow using the response route. This completes this request/response scenario.
  • the sequence diagram in Fig. 12 shows a simple request/response pattern with message correlation used, where the response does not contain enough information to perform route selection to return the message to the request flow. In this case, the request message has been stored in a message correlation table, which is used to correlate a received response to determine the response route. [0099] The following steps are taken in this sequence diagram: a) A consumer in a request flow selects a request route to send a request to a destination flow.
  • the routing component delivers the request to a destination flow using the request route.
  • the destination flow stores the request in a message correlation table.
  • the endpoint is selected based on information in the request message.
  • the endpoint sends the request over the network to an external system.
  • the external system responds to the request on the same endpoint.
  • the endpoint delivers the response to the correlate message flow.
  • a consumer in the correlate message flow uses data in the response to select the original request from the message correlation table.
  • the select response route consumer uses data in the original request message to select the response route.
  • the routing component delivers the response to the destination request flow using the response route. This completes this request/response scenario.
  • FIG. 13 the end-user is at the top of the diagram, building a set of configurations to combine everything into a transaction processing application. Arrows indicate dependencies. Shaded boxes represent existing product components.
  • Services implement behavior for higher-level business applications. Many services will be encapsulated by higher-level solution pieces, and therefore may be hidden from the end-user. If a service is visible to the end-user, that service is typically only configurable by the end-user, not customizable e.g., message transformation as used in application flows.
  • a framework is a customizable component.
  • Each framework prescribes an extensibility mechanism; higher-level pieces provide the customization and hide the details from the end-user. Some frameworks provide administration interfaces directly to the end-user (for instance, the SAP framework where SAP stands for "standard access point”).
  • SAP framework where SAP stands for "standard access point”
  • Components are built closest to the end-user. They are configurable, but not customizable. The end-user combines pieces from all layers into a unified application with configuration data.
  • the routing component encapsulates outbound and cross-node message routing decisions in a single entry point.
  • the routing service selects the best available path within a route and delivers a message to that path. This may include routing across transaction processing nodes, if needed. Routing can deliver messages to an SAP, channel, or flow. In one example, the routing service is reachable via an API. Access to routing may be wrapped in a message consumer for flow integration.
  • the routing service generally provides some configuration but no extensibility.
  • the transformation service provides a declarative way to map message contents from one schema to another.
  • the transformation service may be used, for example, by SAP instances to map from a channel- specific form to a normalized message definition.
  • the transformation service may also be used for message field validation, for example.
  • Transaction processing applications may also use the message transformation service to convert messages - for example, to convert between vastly dissimilar processing networks, independent of a particular channel selection.
  • Individual transformations may be configured in a transformation language. For example, the build process may generate a flow consumer that an application designer can simply "drop" into a flow. This is a configured service that builds a flow element.
  • the transaction processing architecture defines three significant "framework" pieces.
  • the Business Entity framework represents one service capability of an external entity with an established presence within a transaction processing platform. Examples of a Business Entity for electronic payment transaction processing applications may include, for example:
  • a business entity in this context typically represents a single service capability of the entity, rather than a physical or accounting role (for an electronic payment application).
  • a given electronic payments processing center may have separate applications for credit and debit transactions; this may be modeled in an electronic payment processing application as two business entities.
  • the business entity combines metrics, behavior, and extension points, and may include some of the functions discussed later. It is noted that the business entity framework generally does not contain much data. This may be, rather, a flexible container for customer-specific objects, as determined by the application.
  • a Business Entity may provide a single way to combine customized application data, partitioned by customer. It may also define a single state transition notifier to simplify development of application services using this data. Many value- added services have some customer aspect. Consider the following as representative examples; in an electronic payment transaction processing application.
  • the Business Entity typically minimally includes transition notifiers for:
  • Each Business Entity manages an HA partition. Higher- level components may store customer- specific mirrored data in this partition. Each Business Entity typically manages one Route and all that Route's associated endpoints. The Route state determines the customer state (more generally, the entity represented in the transaction). In one example, a Route chooses a Path based only on availability, not message content. The selection of a destination Business Entity qualifies directly to the right Endpoint for this message type, SAP notwithstanding. [0115] A Business Entity inherits state from its Route. Activation of the configuration group will set the Business Entity up in the Initializing state; deactivation of that group will destroy the Business Entity.
  • the Business Entity publishes a transaction switch event for each state transition.
  • the Business Entity type includes an abstract state notifier that allows components to register a callback for each state transition.
  • Application services may use this callback to manage their own state both locally and cluster-wide.
  • Setup and teardown of the Business Entity may be via configuration.
  • the runtime state is managed by the Route.
  • Route administration may be wrapped as BE targets to present a coherent picture to the user.
  • correlation may use various message fields to find the relationship between the messages, such as to find the relationship between a request, a response, and a reversal message for the same transaction (such as, for example, a credit transaction).
  • the actual fields used per message may vary with the message type; this may be configurable and, in some examples, defined no earlier than message normalization or later.
  • Message correlation is a flow component that is inserted as appropriate in an application flow by the solution/project designer.
  • the correlation table holds state of individual messages as the network interactions represented by those messages are pending. This managed state also includes timing; correlation may inject an event into a configured application flow when a timeout occurs.
  • the Channel Adaptor framework normalizes the application-channel interface.
  • Channel Adapter instances may access Channel Adapter instances via the Routing service, which is in turn wrapped by the Business Entity.
  • the Channel Adaptor framework allows an application to define its own message schemas using a message transformation language. Customization may occur on a per-channel, per-application basis.
  • Some examples of features achieved via Channel Adaptor extension may include: • journal business messages as they touch the network;
  • the correlation features may be used to assist in high availability. That is, a solution using the transaction processing platform is a distributed system with crucial in-flight data made highly available.
  • the correlation cache maintains data for the inflight business transactions to make that transaction data highly available.
  • the HA characteristics fit customer environments even where there may be no control over either the connection behavior or the exchange message protocol.
  • Fig. 14 shows a simplified view of a typical deployment of a transaction processing solution for illustration and discussion.
  • the external system for business X connects to 3 nodes in the gateway: A, B, and C, while the external system for business Y connects to 3 nodes in the gateway: D, E, and F.
  • nodes A, B, and C form a cluster for business X
  • nodes D, E, and F form a cluster for business Y.
  • Requests received by node A with a destination for Business Y are sent over to node D, E, and F, and the responses come back through these nodes too, as indicated by the gray arrows.
  • the internal traffic for node B and C is not shown. Load balancing may be achieved by the external application distributing traffic among connections to nodes, and also by the system internally distributing traffic among nodes connecting to the other business handling requests.
  • Fig. 15 shows a typical request/response pass-through scenario.
  • Business X sends the gateway a request, which is received by node A, forwarded to node D, and sent out to Business Y.
  • Business Y sends back a response to node D, and the response is forwarded to node A, which forwards the response to Business X.
  • the request is put on the correlation cache, and the correlation entry removed as a result of the response. This is a typical scenario, as the message flows through normally, there is no down node.
  • the correlation cache may "live" on the destination side of the request on the system, in the Fig. 15 example, node D, E, and F. For example, when node D goes down before the response comes back, the correlation cache becomes active on node E. But since the connection between node D and Y is gone (due to node D going down), Y will select another path to send back the response, and the path Y to E is just one of the possibilities. If the response comes from the path Y to F, the response may be horizontally routed to node E since E now holds the correlation cache from D.
  • the correlation cache may "live" on the source side of the request, in the above example, node A, B, and C, and, if there is a way to figure out which partition the request has gone through from the response, then, no matter which path the response takes from Y to the gateway, either of the nodes D, E, F will be able to figure out that the response should be routed to that partition.
  • D is down
  • the response will still go back to A, as shown in Fig 16. If A is down, the response goes to the partition, which has become B.
  • a reserved field is used in the exchange message. This may not be feasible as the exchange message format may be uncontrollable.
  • a second option Option 2 - STAN hint
  • a hint is used in the STAN (System Trace Audit Number).
  • the "mod" function of the STAN is used. For example, if the STAN assignment is to give, to each partition, STANs with equal mod, the partition can be inferred from the STAN number. For example, for four partitions - A, B, C, and D- A may be assigned a STAN of 0, 4, 8, 12, etc.; B may be assigned a STAN of 1, 5, 9, 13, and so on.
  • STAN blocks are utilized and the STAN block information is distributed.
  • partition A may have a block from 1000 to 1100.
  • every node knows that the block from 1000 to 1100 has been assigned to partition A.
  • one partition is assigned, to be the request receiving partition, per business entity. Messages are received on multiple nodes but are all routed to the particular assigned partition. This can be useful, for example, if most of the external business applications use the connections preferentially, meaning most of the traffic go to one node normally. Even though this option may include a horizontal routing step upon incoming requests, the horizontal routing is skipped because the correlation cache will live on the preferred node.
  • the Business Entity class is distributed, such that the Business Entity instance "lives" on all nodes, and a downed node does not bring down the Business Entity.
  • the Business Entity wraps up the Route class: the Business Entity is globally known, and the status is updated globally.
  • a Business Entity has one to many correlation cache partitions, which are implemented as HA mirrored objects.
  • a Business Entity has one STAN manager. The Business Entity is loosely coupled with the Correlation Cache and the STAN manager.
  • a local routing Path instance has a Channel Adaptor to handle inbound/outbound messages.
  • a remote path passes outbound messages to the node, where the path is local.
  • Each Channel Adaptor has one associated endpoint associated.
  • Each endpoint has one to many sessions.
  • the Business Entity may have a correlation cache on each node where the external application is connected, and Responses go back to the individual correlation cache where the request is inserted.
  • the fourth option one partition
  • only one correlation cache is defined for a business entity, and all responses are routed to the correlation cache partition.
  • a control object is provided to record information about from where a request originates to where a response should be provided.
  • the information in the epayment control object is only used at the application level, and SAPs do not need to know about this control object.
  • the following table lists the usages of SDU fields supported in a sample solution for authorization type of messages. SAPs are compliant with these usages. This table documents how the epayment solution may: • change the request. The epayment system may change some values before it forwards the request on.
  • the epayment system may change some values before forwarding the response on.
  • the epayment system may generate a response based on an incoming request.
  • the epayment system may generate responses in two cases, for example: when the negative file record is checked and it is appropriate to deny an authorization request, and when a request times out. When a request times out it is also possible to simply remove the correlation entry and not generate a response.
  • the notations in the example presented in the table are:
  • ActionCode by checking the PAN against the negative file records, if it is determined to deny an authorization request, the actionCode is populated with PickUpAndDoNotHonor.
  • STAN the epayment system changes the STAN. For requests a new STAN is assigned. For responses the original STAN from the request is lost. The external business application may have a mismatch on the STAN.
  • MessageErrorlndicator the epayment system may set the Message Error Indicator group to report back message errors, in which case the request or the response would be rejected and routed back to the originator.
  • NetworkRejectHeader When an internal processing error happens, the NetworkRejectHeader is populated to reject the request or response.
  • the extension can live in a component other than the rudimentary epayment SDU definition package, along with the processing logic to handle the SDU extension.
  • the transaction classifier chooses an appropriate application flow for a message.
  • the transaction classifier attempts to determine if the transaction message is part of an existing business transaction. If so, the message is dispatched to an appropriate application flow for that transaction.
  • the classifier may find no business transaction exists for that message, and route the message accordingly to an application flow.
  • the classifier is a combination of simple flow rules.
  • the transaction classifier component may firewall the application from the channels. For example, a Channel Adaptor may blindly drop a message on the transaction classifier and trust that it will be delivered to an appropriate application.
  • the Transaction Classifier is a classifier, and is defined by the end-user in a flow specification.
  • the trace number component also sometimes called STAN
  • a set of risk management components are defined.
  • a Negative File application provides a list of accounts (more generally identifications) for which transactions should be automatically refused. This component provides the negative file lookup capability to authorization applications.
  • a session monitor component checks the cluster-wide state of a Business Entity on a regular basis to validate certain metrics. Each Session Monitor is configured to look after one Business Entity. The session monitor may be a global maximum session count; the monitor will check that the BE is using less than its configured maximum. Any sessions found to be over the limit will be terminated. [0139] A journal transfer component is responsible for moving financial journals to offboard systems for archiving, viewing, etc.
  • Logger is a platform service that may be used by any application flow with a system-of-record logging requirement. It may also be used by SAP instances for logging at the network interface.
  • the Channel Adaptor framework includes built-in behavior and defined customization points (for example, the transformation service). It also defines an extensibility mechanism for specific Channel Adaptor types to add behavior. [0142]
  • an application flow can begin, for example, by a message arriving from external business entities, via a Channel Adaptor; a peer node in the cluster; or a message timeout from the correlation table.
  • the message is dispatched to the transaction classifier.
  • the transaction classifier refers to the message correlation table to determine if this message is connected with an existing business transaction. If the message is part of an existing business transaction, an application flow is selected according to the state of that business transaction, and the message is dispatched. [0144] If the message is a new message, an application flow is selected and the message is dispatched. The application flow creates a new business transaction if one is warranted, and registers the business transaction with the message correlation table. [0145] The application flow box in Fig.
  • 17 may represent a system implemented by many individual flows - request, response, timeout, error flows. From the point of view of the transaction classifier, there is a single defined flow entry. The set of application flows may be user-extensible. [0146] It may be noted that the distributed routing component is the only message sink - horizontal routing is encapsulated behind the general node/endpoint lookup facility.
  • a message type is determined and forwarded to specific handling flows. All inbound SAPs link to this flow. Internally created messages are usually injected to this flow as well. Each message type specific flow is linked after the classification flow. [0150]
  • the authorization flows handle all scenarios in the authorization transactions. Other message types follow a similar design to the authorization flows.
  • the shaded modules in the figures indicate network hops.
  • the classifier in the classification flow sends all inbound requests to the authorization request flow.
  • This flow can be typically setup as shown in Fig. 19.
  • the authorization requests (in this example, for an electronics payment application) go through the following steps of processing:
  • SAP This is on the local node for the request where it is received by the transaction processing system.
  • the negative file records are distributed over to all nodes, and the negative file records become global to all nodes on the cluster. As a decision on authorization may result from this step, it may be more efficient to let the decision be made early rather than later.
  • the source Business Entity is determined. It is exceptional if there is no source business entity.
  • the PAN is used to determine the destination Business Entity. For example, the first 4 digits of the PAN may determine the receiving business entity of the request. If the destination business entity can not be determined, the request is rejected and sent back through the incoming SAP to the external business entity originating the request.
  • the request is forwarded by the routing service to a path for outbound. Usually a local path is chosen if it exists for outbound messages.
  • the correlation cache timeout can generate a response message and inject the response message into the classification flow.
  • the routeToSTAN step will find that the message is to be handled locally, and it goes to correlation removal, and forwarding would be local in this case too. There is no need for a dedicated flow for authorization timeout, and solutions can still configure a timeout flow if it is desired.
  • the transaction processing system is designed to be a high-performance system. Performance include scalability, throughput and latency. Scalability includes scaling on a single node and scaling by nodes. On a single node, the multi-core hardware architecture may be employed. On a distributed network, more nodes add to the complexity and the higher data traffic and higher CPU consumption, but each node gives more computing power and the throughput would generally improve with the number of nodes.
  • Fig .21 schematically illustrates an example of the development methodology and environment.
  • service adaptors 2104 are determined to accomplish the process.
  • the service adaptors 2104 include transaction processing services 2106 as well as application business logic services 2108.
  • Fig. 22 shows the implementation of Fig. 21 in greater detail.
  • the development environment is based an Eclipse framework with customized plug-ins to integrate the Service Adaptors, Services and Business Logic.
  • the process definition 2202 may be provided by a user by interacting with a set of graphical templates, an example of which will be described later.
  • the process 2202 can be mapped to a number of service adaptors including, in the example, network management 2204, credential exchange 2206 and authorization 2208.
  • the composition, ordering and functionality are determined by the design and purpose of the application.
  • the implementation of the process 2202 shown broadly by 2210 and in more detail by 2212 will ensure the resulting application is fully transactional.
  • the implementation of the service adaptors includes the transaction services "Log Result" as an example, and also includes the business logic "Find Destination.”
  • the resulting application (arrangement of transaction services and business logic services) is fully transactional.
  • “Fully transactional” means that the normal ACID properties of a transaction are preserved (Atomicity, Consistency, Isolation and Durability). With regard to atomicity, it is guaranteed that all data and events are either committed or not. It is assured that an event is delivered once and only once, as well as atomic data modifications. With regard to consistency, data consistency within a transaction is guaranteed. For example, any constraint violation (e.g. deadlock) causes all data modifications to be rolled back and all events to be replayed. [0161] With regard to isolation, transaction isolation is provided for multiple concurrent transactions. Serializable and "dirty read" isolation semantics may be supported.
  • an IDE is based on Eclipse, which is a popular, extensible, open-source software development framework.
  • the IDE is an extension of Eclipse, adding transaction platform specific features and interoperability with a transaction processing application design center.
  • the IDE is used to assemble a set of project elements that define the application, without the need to be concerned that the resulting application instantiation will be fully transactional.
  • the IDE itself automatically insures that the resulting application instantiation will be fully transactional.
  • Fig. 23 An example of an IDE display is provided in Fig. 23.
  • a pane 2302 is provided to select design elements to edit.
  • a portion 2304 of the Fig. 23 display displays the current status of builds, audits and other commands.
  • a canvas portion 2306 graphically illustrates a currently-defined configuration of elements at some level of the application hierarchy.
  • Fig. 24 illustrates an example of the canvas portion 2304 in greater detail. In particular, Fig. 24 illustrates a process diagram with three tasks and two gateways. The steps in the process are joined by links, which define the sequence in which the steps are performed. New processes may be created from scratch, or existing processes may be imported from other applications.
  • a process includes an ordered set of steps, such as tasks and gateways.
  • a task is a piece of business logic and a gateway is a decision point.
  • a step within a process may use some other processes defined by one or more separate process diagrams.
  • a process used in this way is sometimes referred to as a sub-process.
  • a gateway provides a branching point within a process, containing several gates, each of which defines one branching route from the gateway.
  • Steps within a business flow are linked together to specify the sequence in which the steps are performed. In one example, the following types of gateways are possible: default; unconditional (always followed); and conditional (which is followed according to occurrence of a specified condition).
  • the application receives requests through channels and those requests are operated upon by business processes.
  • a request itself is contained in a message.
  • Messages may be made of message blocks.
  • a request to charge for a phone call may have a header block, a block to identify the caller, a block to identify the receiver of the call, and a block to identify the details of the call.
  • the data to be stored in each of these message blocks may be defined using the IDE.
  • each message block is defined as a data structure.
  • a message editor may be used to define message blocks, and the message blocks grouped using message containers.
  • channels convert data received from some external protocol into a normalized form.
  • the IDE provides facility to graphically design mapping rules.
  • message blocks may be dragged into source and target areas.
  • the editor generates simple assignments by default, which can be customized by a user interacting with the editor.
  • the message mapping is saved as a process by the editor, which can then be used to map message blocks anywhere in the application such as, for example, by dragging the process onto a process diagram, connecting the input and output into the process definition.
  • Fig. 24 illustrates an example of the message mapping editor interface.
  • the IDE also provides facility for configuring an application using configuration files. For example, the following may be configured: inbound and outbound message routing, message processing, security, application management, and event handling. Such files may be created, imported and modified within the IDE. [0172] We now discuss configuration of routing within a transaction processing application.
  • a routing service is provided to determine a "best" communication path between an application and a logical destination.
  • a routing table defines alternative paths that comprise one or more logical destinations (known as routes) and configures how to select between the paths.
  • Paths may be added or modified from within the IDE. Properties of paths may include name, priority (relative priority of the path), address (where messages are routed for this path), inactive path polling frequency, statistics update frequency, and description.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un procédé de développement de traitement de transaction qui utilise un cadre d'applications de développement de traitement de transaction pour faciliter le développement d'une application de traitement de transaction souhaitée. Une pluralité d'adaptateurs de service sont fournis. Une infrastructure est fournie, par l'intermédiaire de laquelle une logique applicative définie par un utilisateur de l'application de traitement de transaction souhaitée peut être fournie au cadre d'applications de développement de traitement de transaction. La définition de la logique applicative est traitée pour instancier l'application de traitement de transaction, comprenant l'instanciation d'un sous-ensemble des adaptateurs de service pour mettre en œuvre les services de l'application de traitement de transaction, et comprenant en outre l'agencement des adaptateurs de service instanciés pour accomplir la logique applicative en association avec une logique de traitement de transaction générique. L'agencement des adaptateurs de service est garanti, lors de l'exécution, d'accomplir l'application de traitement de transaction d'une manière qui est entièrement transactionnelle.
PCT/US2008/085874 2007-12-18 2008-12-08 Procédé et système pour développer des applications transactionnelles à l'aide d'un environnement de développement intégré, comprenant une bibliothèque de services pour s'assurer qu'une application de traitement de transaction est entièrement transactionnelle WO2009079258A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US11/959,345 2007-12-18
US11/959,345 US20090158242A1 (en) 2007-12-18 2007-12-18 Library of services to guarantee transaction processing application is fully transactional
US11,959,333 2007-12-18
US11/959,333 US20090158246A1 (en) 2007-12-18 2007-12-18 Method and system for building transactional applications using an integrated development environment

Publications (2)

Publication Number Publication Date
WO2009079258A2 true WO2009079258A2 (fr) 2009-06-25
WO2009079258A3 WO2009079258A3 (fr) 2009-10-01

Family

ID=40796092

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/085874 WO2009079258A2 (fr) 2007-12-18 2008-12-08 Procédé et système pour développer des applications transactionnelles à l'aide d'un environnement de développement intégré, comprenant une bibliothèque de services pour s'assurer qu'une application de traitement de transaction est entièrement transactionnelle

Country Status (1)

Country Link
WO (1) WO2009079258A2 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020107957A1 (en) * 2001-02-02 2002-08-08 Bahman Zargham Framework, architecture, method and system for reducing latency of business operations of an enterprise
US20030088659A1 (en) * 2001-11-08 2003-05-08 Susarla Hanumantha Rao System and method for distributed state management
US20050144226A1 (en) * 2003-11-10 2005-06-30 Churchill Software Services Systems and methods for modeling and generating reusable application component frameworks, and automated assembly of service-oriented applications from existing applications
US20060184569A1 (en) * 2005-02-16 2006-08-17 Michael Aakolk Data processing systems and methods
US20060229888A1 (en) * 2005-03-31 2006-10-12 Renzo Colle Defining transaction processing for a computer application

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020107957A1 (en) * 2001-02-02 2002-08-08 Bahman Zargham Framework, architecture, method and system for reducing latency of business operations of an enterprise
US20030088659A1 (en) * 2001-11-08 2003-05-08 Susarla Hanumantha Rao System and method for distributed state management
US20050144226A1 (en) * 2003-11-10 2005-06-30 Churchill Software Services Systems and methods for modeling and generating reusable application component frameworks, and automated assembly of service-oriented applications from existing applications
US20060184569A1 (en) * 2005-02-16 2006-08-17 Michael Aakolk Data processing systems and methods
US20060229888A1 (en) * 2005-03-31 2006-10-12 Renzo Colle Defining transaction processing for a computer application

Also Published As

Publication number Publication date
WO2009079258A3 (fr) 2009-10-01

Similar Documents

Publication Publication Date Title
US20090158246A1 (en) Method and system for building transactional applications using an integrated development environment
Daya et al. Microservices from theory to practice: creating applications in IBM Bluemix using the microservices approach
Li et al. A distributed service-oriented architecture for business process execution
US20120324069A1 (en) Middleware Services Framework for On-Premises and Cloud Deployment
US5937388A (en) System and method for performing scalable distribution of process flow activities in a distributed workflow management system
US5870545A (en) System and method for performing flexible workflow process compensation in a distributed workflow management system
US5826239A (en) Distributed workflow resource management system and method
Megargel et al. Migrating from monoliths to cloud-based microservices: A banking industry example
US20090063664A1 (en) Systems and/or methods for location transparent routing and execution of processes
Fehling et al. A collection of patterns for cloud types, cloud service models, and cloud-based application architectures
Schmutz et al. Service-oriented architecture: an integration blueprint: a real-world SOA strategy for the integration of heterogeneous enterprise systems: successfully implement your own enterprise integration architecture using the trivadis integration architecture blueprint
US20090158242A1 (en) Library of services to guarantee transaction processing application is fully transactional
Beckman et al. Exascale operating systems and runtime software report
Chawla et al. Building microservices applications on Microsoft azure: designing, Developing, Deploying, and Monitoring
Ritter et al. Exception handling in message-based integration systems and modeling using BPMN
Petriu et al. Software performance modeling
US8626716B1 (en) Service broker enhancements
Elmagarmid et al. Workflow management: State of the art versus state of the products
Herness et al. WebSphere Application Server: A foundation for on demand computing
Goniwada et al. Cloud native architecture and design patterns
WO2009079258A2 (fr) Procédé et système pour développer des applications transactionnelles à l'aide d'un environnement de développement intégré, comprenant une bibliothèque de services pour s'assurer qu'une application de traitement de transaction est entièrement transactionnelle
Filho et al. A fully distributed architecture for large scale workflow enactment
Genevra et al. Service oriented architecture: The future of information technology
Chawla et al. Building Microservices Applications on Microsoft Azure
Gesvindr et al. Design of Scalable and Resilient Applications using Microservice Architecture in PaaS Cloud.

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08863019

Country of ref document: EP

Kind code of ref document: A2