Patent Application
20060247936
The present invention relates to the field of commerce computing and more particularly to component based commerce systems.
As businesses and consumers become further interconnected through computer communications networks such as the global Internet and local intranets, the commerce sites and companion computing applications which integrate interactions between businesses and consumers alike can become ever more complex. Addressing the explosion of business to business and business to consumer interactions on-line, information technologists increasingly focus on architecting and implementing complete commerce site solutions to reflect the entire life cycle of a business in lieu of integrating multiple, disparate applications which when combined reflect the business life cycle. Consequently, as modern commerce sites can be both large and distributed, commerce systems have been configured to deploy complete e-commerce systems in as seamless a fashion as possible.
It is now a common trend that traditional, stand-alone, commerce oriented applications are produced from one or more components which can be individually re-used to create business processes for different solutions. Each of these components can expose itself as a set of services comporting with computing standards for deploying enterprise level logic that facilitate an open service oriented architecture (SOA). An SOA essentially can be defined as a collection of services. These services communicate with each other, which communication can involve either simple data passing between two or more services, activity coordinating by two or more services.
In a SOA, a client can invoke a service within a component to perform an operation and, optionally the client can receive a response. Invoked services generally can include business services configured to fulfill the needs of business customers, whether those customers are individual consumers or other businesses. The services can be grouped into various SOA components where each component can specialize in functions such as catalog management, shopping car management, credit card transaction processing, sales tax computation and the like.
By utilizing an SOA, components in a commerce solution can interoperate with other business processes in a larger commerce solution involving one or more separate business entities and one or more separate consumer entities.
Within a traditional commerce platform product, a commerce model represents a commerce solution such as a consumer-direct commerce model, a business-direct commerce model, a supply chain commerce model and demand-chain commerce model to name only a few commerce models. Commerce models can be assembled from a set of common components to achieve the desired affect represented by the commerce model. As such, with a high demand placed upon component re-use, a method to adapt components into a commerce model can avoid having to customize the component for each solution.
Within a commerce model, stateless transactions can be combined to form an activity in the aggregate. The context of the activity can be maintained centrally by the commands forming the basis of the commerce system implementing the commerce model. The context can include aspects of an activity such as the parties to the activity, the resources supporting the completion of the activity, and the medium of the activity. For example, contextual data can include a store identifier, a common language identifier, or a currency type.
The use of centralized context management requires the proprietary management of contextual data outside of the scope of the components defining the commerce model. In this regard, session management can be used to persist an activity across multiple requests such that the context of the activity associated with the requester need not be re-established on every request. Communicating with the session management portion of the commerce system, however, can require knowledge of the interface of the session management portion and can inhibit the realization of an SOA architected commerce system.
According to one aspect of the present invention, a method for adapting commerce system components in an SOA through business contexts can include determining a set of required business processes for a proposed solution. Existing ones of the commerce system components in the SOA can be identified as being able to support the set of required business processes. Also, new commerce system components can be created such that the existing ones of the commerce system components and the created components in combination support the set of required business processes for the proposed solution
According to another aspect of the present invention, a set of contexts can be selected to adapt the existing ones of the commerce system components and the created components to support the set of required business processes for the proposed solution. In this regard, the selecting step can include selecting a set of contexts including a base context. The selecting step further can include selecting an additional context selected from the group consisting of a globalization context, a content context, a task context, an entitlement context, and an audit context. Finally, an activity for the proposed solution can be created utilizing the selected set of contexts.
According to yet another aspect of the present invention, the step of creating an activity can include creating an activity for supporting a call center solution for each of a telephone service representative and a customer calling the telephone service representative. Also, an audit context can be provided for use in the created activity. The step of creating an activity alternatively can include creating an activity for supporting a catalog management task, and providing a content context along with the created activity to limit a scope for changes to content in a catalog. Finally, the step of creating an activity alternatively can include creating an activity supporting a marketplace portal solution, and providing an activity token for each store in the marketplace visited by a shopper.
Other aspects and features of the present invention, as defined solely by the claims, will become apparent to those ordinarily skilled in the art upon review of the following non-limited detailed description of the invention in conjunction with the accompanying figures.
As will be appreciated by one of skill in the art, the present invention may be embodied as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium.
Any suitable computer readable medium may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a nonexhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a transmission media such as those supporting the Internet or an intranet, or a magnetic storage device. Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as Java7, Smalltalk or C++. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the “C” programming language. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The present invention is a business context model adapted for use in a commerce system. In the present invention, the business context model can include a method, system and apparatus for managing business contexts for adaptable SOA components in the commerce system. Specifically, a business context engine can provide and manage the contexts that dictate the behavioral characteristics of business components over the lifetime of an activity in a commerce session. By selecting a proper set of business contexts for a particular commerce solution, the contexts can alter the output of the business process of the solution based upon solution requirements without requiring modifications to the SOA component code forming the commerce solution.
The Web application 105 can be communicatively coupled to a component logic container 145 which in turn can be communicatively coupled to persistent storage 190. The Web application 105 can host a servlet engine 110 which can process requests 125 for commerce services through an action servlet 115. The action servlet 115, in turn, can be configured to invoke actions 120 logically linked both to a commerce application view 130 and also to a component facade 155 programmed to invoke business logic within one or more components 165 disposed with the component logic container 145.
For instance, the component facade 155 can be a component stateless session bean (SSB) logically coupled to one or more components 165 which when combined form a commerce system solution. Each of the components 165 can include a controller command 170 having one or more task commands 180. The controller command 170 further can be logically linked to access logic 175 configured to access persisted data in the database 190. Similarly, the commerce application view 130 can include access logic 135 likewise configured to access persisted data in the database 190.
Notably, the component facade 155 can be coupled to a business context engine 150. The business context engine 150 can manage an activity, where the activity can include a series of consecutive requests 125 from one or more service clients, in order to treat the consecutive series of requests 125 as a single conversation as between the service clients and the commerce system service defined by the components 165. The context engine 150 is responsible for managing the business contexts associated with an activity.
As it will be apparent from the schematic illustration of
As shown in
In operation, the client computing process 210 can obtain an activity token from the business context engine 230 which can include a specific set of business contexts. The client computing process 210 subsequently can pass the activity token to the business component 220 in the course of a business task in order to provide contextual information for completing the task. For instance, the business component 220 further can access elements of the business contexts 280 by way of an application programming interface (API) to the business context engine 230 utilizing the specific information of the activity token.
To invoke a method on a business component, a client 210 or component facade 240 can obtain an activity token by first making a call to the interface of the business context service 270. In the process of obtaining the activity token, the client 210 or component facade 240 optionally can supply initialization data that can be used to populate pre-loaded contexts during creation of a new activity. Subsequently, the client 210 can pass the activity token to the component facade 240 when a particular method is invoked on the interface to the business component 220.
The activity token can be used to associate a set of contexts in effect during particular client requests to the various business components. The client can supply the activity token on every request to indicate the experience that the client would like from the business components. These contexts can include, by way of example, a solutions context indicating whether a requested operation in an activity is to be performed by a specified entity, or through an entity which acts on behalf of a specified entity. The contexts also can include a globalization context providing globalization information, an entitlement context providing information for promotional entitlement programs, a content context providing versioning information for specified content, a task context indicating a current task or state for an process having multiple tasks, and an audit context providing auditing information, to name only a few contexts.
A base context can be provided which exists for each activity. The base context can include a store identifier under which the activity can be bound. The base context further can include a caller identifier used for authentication, and a run as identifier used by the business logic. The globalization context can indicate globalization attributes for an activity such as language, currency, and locale. In this regard, the globalization context contains the globalization preferences of the client. The entitlement context can hold information regarding a current contract, a session contract and eligible contracts. The task context can be used to indicate a task among a set of tasks currently being performed by an administrator. Finally, a content context can hold information related to a task, workspace, and project under which authoring operations are being performed.
The context of a business task can be maintained across one or more business contexts which can be incorporated into or referenced by activity tokens passed between the different business components when processing the task. Consequently, the state of each business context can be maintained across requests and transactions.
Multiple business components can operate within the same process address space such as the same virtual machine. In this circumstance, each of the components can share the same business context engine. Accordingly, the passing of an activity token containing or referencing the context for an activity can occur directly as between the components in the course of an intra-component call. Specifically,
As shown in both
The business contexts in turn provide the data and services required by the components. Specifically, business contexts can have the following characteristics: —A context can establish an execution environment that affects the output of a business component for equivalent input based upon the solution requirements. —The output produced by a business component for a given input can be identical for the same set of contexts. —Contexts need not be directly invoked by clients of the business processes. Instead the business component can use the services provided by the contexts during the execution of a request. —A context provides a set of service methods and optionally can provide data. —The lifespan of a context starts with the creation of an activity and ends with the completion of the activity.
In further illustration,
The Business Context Service interface 430 can define a number of method members for creating and managing contexts for an activity, including one or more methods for invoking the business context service at the beginning of an activity. For instance, responsive to the invocation of the business context service for a new activity having specified activity data, an activity can be created utilizing the specified activity data. Also, an activity can be created utilizing specified activity data name value pairs. A new activity yet further can be created based upon a clone of an existing activity. Finally, an existing activity can have a new context bound to the activity in order to support dynamic context creation.
Generally, a business context class (not shown) configured for use in the business context services architecture of the present invention can implement two interfaces. The first interface can be an API interface which business components can use to interact with a business context instance and to retrieve or populate context information using data provided by a business context instance. The second interface can be a service provider interface (SPI) used by the business context service to create a business context instance and to indicate to the business context instance when the business context instance is to populate its data members with initialization data, when the business context instance is to persist its data members, when the business context instance is to reload its data members form a persistent media, and when the business context instance is to clone itself.
As an example, the APIs of the Business Context Service can include: —begin( . . . )—The component facade can call the begin( . . . ) method to obtain a new activity. The activity can be associated with new business context instances defined in a configuration file. —complete( . . . )—The component facade can call the complete ( . . . ) method to terminate an activity and destroy its associated set of business context instances. —clone( . . . )—The component facade can create a new activity by replicating the information stored in an existing business context instance.
The SPIs, of the Business Context Service by comparison, can include: —startRequest( . . . )—A business component can call the startRequest( . . . ) method before performing any context related operations for a request or transaction associated with an activity. Consequently, the business context service can perform any necessary pre-processing related to the contexts associated with the activity. —endRequest( . . . )—A business component can call the endRequest( . . . ) method after performing all context related operations for the current request or transaction associated with an activity. Consequently, the business context service can perform any necessary post-processing related to the contexts associated with the activity. —bindContext( . . . )—The bindContext( . . . ) method permits a business component to dynamically associate a new context with an activity. —findContext( . . . )—The findContext( . . . ) method permits a business component to retrieve context information associated with an activity. —updateContext( . . . )—The updateContext( . . . ) method permits a business component to update a context.
Notably, the Business Context Service Implementation class 410 can be accessed in many ways, including through a stateless session bean and through a Web services wrapper. In more particular illustration,
To construct a solution using the SOA architecture of the present invention, a solution builder can assemble a set of business processes using a set of SOA components. Business context services can ease this task, as context services can make the components adapt to each other and also to the solution.
In block 630, it further can be determined which new business contexts are required for the new solution without also requiring a change to the SOA components. Subsequently, in block 640 any missing components can be created. To create a missing component, one must understand how the new component can be used for the existing solutions. Solution specific behaviors are identified and implemented as business contexts. Finally, it can be determined in block 650 how an activity for the solution is to be created. In this regard, an activity for a business process can span multiple components and multiple transactions.
For instance, a call center solution implementing according to the foregoing process can include an activity for the telephone sales representative and an activity for each calling customer As part of the log-on process for the sales representative, a “begino” operation can be called on the business context service. The begin( ) call can create a first activity for the sales representative in which the sales representative is assigned both to as the caller identifier and the run as identifier. For all non-order operations, this activity will be utilized. As customers call the sales representative, however, a “clone( )” operation can be called using the context of the already created activity to create a new activity for the calling customer. In that instance, the sales representative can remain associated with the caller identifier, but the customer can be associated with the run as identifier.
In all cases, the activity token can be passed for all operations in the call center such that the operation can retrieve the context of the activity to determine which customer, if any, is involved. Moreover, additional contexts can be utilized in the call center scenario. For example, an audit context can be provided with every call to business logic so that the business activities of the sales representative can be monitored across all calling customers. Since an activity is mapped to a customer served by a sales representative, the business audit context can produce reports depicting a length of time taken by the sales representative to service each customer, and how many customers are services by the sales representative in a given period of time.
In comparison to a call center, a catalog content solution also can be created according to the process of the present invention. In the catalog content solution example, the content of a catalog can be scoped such that additions to the catalog can be limited in view depending upon the viewer. To support the scoping of items in a catalog, when managing the content of a catalog, an administrator can be assigned to a task responsible for the management of the catalog. Changes performed in that task will not be made visible to other tasks until the changes are approved and promoted to the base catalog. Specifically, a task context can be added to a current activity when the administrator accepts a task. The content task can separate data between tasks. For example, prior to the invocation of a component in the activity, the content context can select for use in accessing data in a data store, a suitable schema associated with the current task. The selected schema can result in the retrieval of the desired content from the catalog content.
Finally, a marketplace portal solution can be created according to the present invention. In the marketplace portal solution, a set of businesses or stores can provide users a rich selection of products and buying opportunities. When visiting a marketplace portal, the shopper can visit multiple stores and place orders in different stores. By providing a different activity per visited store, the interactions with different stores in the marketplace can be monitored seamlessly. Also, for stores that the shopper has already visited, an existing activity can be utilized for that store so as to avoid the unnecessary creation of additional activities.
The flowchart and block diagrams illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It is apparent to one skilled in the art that numerous modifications and departures from the specific embodiments described herein may be made without departing from the spirit and scope of the invention.
