Patent Application
20140067480
Legacy applications are typically standalone applications deployed and operating within an enterprise and provide various kinds of services to users. Legacy applications are typically intended for interactive use by the users/operators, and can employ a variety of record locking mechanisms of ensuring that changes are applied to data in an orderly manner. For example, some applications will first lock a record, then process any updates, and unlock the record only when the transaction is confirmed as completed. This is known as “pessimistic” record locking. In other implementations, an application may accept the entered data, check for additional updates to the same record and process the update if no other updates conflict. This is known as “optimistic” record locking. The work flow of the application may also alter the way changes to data are processed and applied. For example, a record may only be locked when the operator selects an option to maintain a record, or a record may be locked while the operator performs several steps in a particular process.
When an application is being used in an interactive session, a “state” of the application may be used to describe the status of the application and its connection to the underlying data supporting the transactions. For example, during an interactive session, the application is aware of who the operator is and the current context of the work the operator is performing. The context of the operator's session may vary depending of the actions being performed. For example, the operator may be working with a specific customer record. The business logic within the application may determine if the operator has exclusive access to the customer record for the duration of a process (a series of actions), for the duration of a single action, or if the data is shared. For some legacy applications, this state is essential to ensuring the integrity of the data it is responsible for managing.
Legacy applications are typically monolithic, i.e., they are responsible for all aspects of presentation, business processes and data access. Exposing business logic and data from legacy applications to the users as services can present a challenge when applying updates or changes to data that supports multiple independent systems of record. Specifically, services that expose business logic and data owned by the legacy application to other applications in the enterprise are typically designed to be “stateless” and “abstract.” A service is considered to be “stateless” when there is no session that manages the application state outside the invocation of the service, and “abstract” when the user or consumer of the service has no knowledge of how the service is implemented or which applications it interacts with. While it is possible to create fully state-aware, they are not the preferred choice because they require more resources and may limit throughput (the number of transactions that can be executed within a specific time period using resources available), whereas state-less services can make use of resource pooling to increase throughput (essential when considering customer self service).
Additionally, the shift to exposing services to provide access to legacy applications enables the designers of new user interfaces to present the operator with data relevant to their task gathered from many different sources in a manner that mirrors a business process work flow. In such cases, a process such as a two-phase commit is therefore required to ensure data integrity as changes are applied to the data across multiple applications and systems of record.
The foregoing examples of the related art and limitations related therewith are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent upon a reading of the specification and a study of the drawings.
The approach is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” or “some” embodiment(s) in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
The techniques and systems described herein provide a new approach to facilitate enterprise-level context management. As used herein, “context management” is a construct used to manage access and changes to business entities at the enterprise level instead of application level, where the business entities are used by many legacy applications and the underlying data is stored across multiple systems of record. An enterprise context manager is used to enforce the construct, and is implemented as a software layer that secures exclusive access to a collection of related, yet disparate applications and resources ahead of a coordinated multiphase commit. The enterprise context manager provides a complete view of a business entity by presenting various aspects of data of the business entity through a single, unified user interface. It commits changes made to the data managed by two or more legacy applications together or rolls the data back to a pre-commit status if all changes cannot be applied. It is also able to handle changes to data managed by two or more legacy applications that do not share the same commit logic, e.g., one application may use pessimistic record locking while another uses optimistic record locking.
Many organizations operate multiple legacy application over multiple systems of record. In some cases, aspects of data representing a business entity (e.g. a customer) are owned by more than one system of record. Managing context at the enterprise level enables a coordinated multiphase commit across multiple systems of record of data that were never intended to participate in such an operation by multiple applications using existing standards for Web service transactions such as WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity, etc.
As referred to hereinafter, the phrase “context” refers to the current state and scope of a user's interaction with a (legacy) application. It encapsulates who the user is, which business entity or entities they are working with, and which operations they wish to perform on that business entity during a work flow of a business process. As a non-limiting example, Joe is updating the address and telephone number of a customer. The application understands the context of Operator=“Joe”, Entity=“Customer”, Operation=“Update” and will either inform Joe he is not authorized to update the customer's address or will execute the operation and inform Joe the operation was successful. The application will ensure that Joe's change to the customer's address is committed successfully in such a way as to ensure the integrity of the database(s) that store the data. The customer's record may be locked until Joe finishes entering his changes (pessimistic lock), or perhaps the application may check if someone else had changed the customer's address before applying Joe's changes (optimistic lock).
A context may have a scope, i.e., it may apply to all data elements of an entity or a subset of data elements. For example, as depicted in
The performance of tasks and business processes within an organization typically follows a “work flow” and may include use of and interaction with multiple applications. The “work flow” is closely tied with presentation, i.e. what the user sees on his/her terminal when interacting with the application. For example, Joe may take a call from a customer who wishes to place an order and in response Joe selects an option to “Enter new order.” The application leads Joe through collecting details such as identifying the customer, adding products and quantities to the order, selecting a delivery address, selecting a delivery method and accepting payment. In this example there are several entities (Customer, Order, Product) and several operations (Create Order, Calculate Shipping, Process Payment). The “context” describes the resources required to complete a work flow.
The system 100 includes at least one enterprise context manager (enterprise context managing component) 102, integration component 104, and enterprise service bus 106. As used herein, the terms “manager” and “component” refers to software, firmware, hardware, or other components that are used to implement the functional elements of the modules described herein. They will typically include software instructions that are stored in non-volatile memory (also referred to as secondary memory). When the software instructions are executed, at least a subset of the software instructions are loaded into memory (also referred to as primary memory) by a processor. The processor then executes the software instructions in memory. The processor may be a shared processor, a dedicated processor, or a combination of shared or dedicated processors. A typical program will include calls to hardware components (such as I/O devices), which typically requires the execution of drivers. The drivers may or may not be considered part of the engine, but the distinction is not critical.
Still referring to
Each of the components may have a communication interface (not shown), which is a software component that enables the components to communicate with each other following certain communication protocols, such as TCP/IP protocol, over one or more communication networks (not shown). Here, the communication networks can be but are not limited to, internet, intranet, wide area network (WAN), local area network (LAN), wireless network, cellular (e.g., 3G, 4G) Bluetooth, WiFi, and mobile communication network. The physical connections of the network and the communication protocols are well known to those of skill in the art.
Referring again to
In some embodiments, enterprise context manager 102 provides an abstract interface to existing, standalone applications for the purposes of resource management. By presenting a common interface for acquiring secure access to protected resources, enterprise context manager 102 enables standards based, multiphase commit operations over systems that would otherwise be unable to participate in such operations.
In some embodiments, enterprise context manager 102 acts as a default resource manager for the existing, standalone applications that were not designed to consider the concept of resource management across multiple applications. In the case where a system of record secures access to data prior to an update (i.e., a resource manager), enterprise context manager 102 makes use of it. In the case where a system of record does not provide such a mechanism, enterprise context manager 102 acts as a virtual lock server. Conventional, proprietary application-specific virtual lock managers typically serve only a single application and do not necessary interface with resource managers of target systems, thus the burden of maintaining the resources falls on the organization's IT staff. In contrast, the enterprise context manager 102 serves as a virtual lock manager and a resource manager over multiple legacy applications at the same time and does so without creating additional overhead for the IT staff.
In some embodiments, enterprise context manager 102 enables transactional services among many legacy applications which do not support transactional resources and applications. Note that enterprise context manager 102 may be used in conjunction with a conventional transaction manager. Unlike a transaction manager such as IBM Resource Recovery Services (RRS) that enables transactions to update and synchronize protected resources managed by multiple resource managers on z/OS, enterprise context manager 102 works with various kinds of legacy applications not limited to those on z/OS applications that already support the concept of transactional updates. In that regard, the context manager 102 is agnostic as to the operating system or platform of the application it is accessing.
In some embodiments, enterprise context manager 102 applies existing standards for implementing Web services as transactions to expose business logic and data from legacy applications to the users. These standards include but are not limited to:
In some embodiments, enterprise context manager 102 provides an abstraction of context management over legacy applications. So in some cases, enterprise context manager 102 checks a dedicated data source for an existing context and issue a new context if it is available. In other cases, enterprise context manager 102 actually communicates with the backend application to acquire the context by placing an entry in an activity table of a legacy application.
In some embodiments, enterprise context manager 102 is used to implement an authorization mechanism which dictates those operations that are allowed to be performed on an entity within the work flow by an operator. As a non-limiting example, the operator may be permitted to retrieve data about an entity, but may not be permitted to update it.
In some embodiments, enterprise context manager 102 may attach metadata to a context for the duration of the work flow. For example, a routing code may be stored within the context and re-used by some or all of the services that participate in the work flow. The inclusion of the meta data would be invisible to the consumer of the application and the determination of the routing code would only need to be performed once for each instance of a work flow. In some embodiments, the routing code may indicate to which instance of the legacy application a concrete service should be directed.
In some embodiments, instructions from enterprise context manager 102 forms part of the request meta data, and as an example may be carried in the SOAP header. Designers of abstract services that operate on top of legacy resources will specify the context that must be acquired to invoke the service i.e. Entity and Scope. It is quite possible that a service may require a context to include data for several different entities across several systems of record.
Again in the example of
As illustrated in
In the example of
In the example of
In the example of
Within a Service Oriented Architecture (SOA) presentation, business processes and data access are spread over several tiers and many different loosely coupled applications. When exposing services over legacy applications the legacy application is no longer responsible for presentation to the user or for work flow steps that the user will follow when participating in a business process. However, the legacy application is still responsible for any business rules, data access and data integrity. This also means that the legacy application maintains a context for the operations performed by the service implementation. With presentation and work flow being managed in a tier closer to the user, the implementation of a stateless service over the legacy application may break the link between the context and the work flow.
Referring to the example in
In one solution as depicted in
Where there are other applications in the enterprise that access the same legacy applications or resources as shown in
One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
One embodiment includes a computer program product which is a machine readable medium (media) having instructions stored thereon/in which can be used to program one or more hosts to perform any of the features presented herein. The machine readable medium can include, but is not limited to, one or more types of disks including floppy disks, optical discs, DVD, CD-ROMs, micro drive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data. Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human viewer or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and applications.
The foregoing description of various embodiments of the claimed subject matter has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the claimed subject matter to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. Particularly, while the concept “component” is used in the embodiments of the systems and methods described above, it will be evident that such concept can be interchangeably used with equivalent concepts such as, class, method, type, interface, module, object model, and other suitable concepts. Embodiments were chosen and described in order to best describe the principles of the invention and its practical application, thereby enabling others skilled in the relevant art to understand the claimed subject matter, the various embodiments and with various modifications that are suited to the particular use contemplated.
