1. Field of the Invention
This invention relates generally to data processing. More particularly, an embodiment relates to a system and method for performing data processing using shared memory.
2. Description of the Related Art
Traditional client-server systems employ a two-tiered architecture such as that illustrated in
As is known in the art, the “business logic” component of the application represents the core of the application, i.e., the rules governing the underlying business process (or other functionality) provided by the application. The “presentation logic” describes the specific manner in which the results of the business logic are formatted for display on the user interface. The “database” 104 includes data access logic used by the business logic to store and retrieve data.
The limitations of the two-tiered architecture illustrated in
In response to limitations associated with the two-tiered client-server architecture, a multi-tiered architecture has been developed, as illustrated in
This separation of logic components and the user interface provides a more flexible and scalable architecture compared to that provided by the two-tier model. For example, the separation ensures that all clients 125 share a single implementation of business logic 122. If business rules change, changing the current implementation of business logic 122 to a new version may not require updating any client-side program code. In addition, presentation logic 121 may be provided which generates code for a variety of different user interfaces 120, which may be standard browsers such as Internet Explorer® or Netscape Navigator®.
The multi-tiered architecture illustrated in
For example, in a J2EE environment, such as the one illustrated in
In recent years, as business application development projects have grown larger and more diversified, integration of business applications in terms of people, information, and processed is becoming increasingly important. SAP®) NetWeaver™ was developed and presented by SAP AG with core capabilities to provide a solution for the integration of people, information, and processes.
However, the integration of people, information, and process is resulting in an ever increasing demand for high-level planning, maintenance, and administration, which in turn, requires the underline architecture and environment to conform to, for example, platform independence, inter-process communication, increased security, development versioning, multi-user possibility, shared memory, and efficient classloading. For example, it would be useful to have an architectural environment that provides increased robustness, improved integration, better monitoring, reduced memory footprint, decreased internal threads, faster session failover, and shared memory.
A system and method are described for performing data processing using shared memory. In one embodiment, a request to perform a transaction is received at a memory. The memory includes a shared memory to provide a common access to a plurality of components including a plurality of work processes and a plurality of worker nodes. The request is then cached at the memory and later assigned to an available work process for performance.
The appended claims set forth the features of the invention with particularity. The embodiments of the invention, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings in which:
Described below is a system and method for employing performing data processing using shared memory. Throughout the description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the present invention.
In the following description, numerous specific details such as logic implementations, opcodes, resource partitioning, resource sharing, and resource duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices may be set forth in order to provide a more thorough understanding of various embodiments of the present invention. It will be appreciated, however, to one skilled in the art that the embodiments of the present invention may be practiced without such specific details, based on the disclosure provided. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.
Various embodiments of the present invention will be described below. The various embodiments may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor or a machine or logic circuits programmed with the instructions to perform the various embodiments. Alternatively, the various embodiments may be performed by a combination of hardware and software.
Various embodiments of the present invention may be provided as a computer program product, which may include a machine-readable medium having stored thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process according to various embodiments of the present invention. The machine-readable medium may include, but is not limited to, floppy diskette, optical disk, compact disk-read-only memory (CD-ROM), magneto-optical disk, read-only memory (ROM) random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical card, flash memory, or another type of media/machine-readable medium suitable for storing electronic instructions. Moreover, various embodiments of the present invention may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
Information integration 204 refers to converting information into knowledge quickly and efficiently. Information integration 204 provides efficient business intelligence 216 and knowledge management 220 using SAP products like Business Information Warehouse (BW) and Knowledge Management (KM). Further, consolidation of master data management 218 beyond system boundaries is performed using SAP's Master Data Management (MDM). Process integration 206 refers to optimized process management using integration broker or SAP exchange infrastructure 222 and business process management 224 techniques. Examples of products to perform process integration 206 include Exchange Infrastructure (XI) and Business Process Management (BPM).
Application platform 208 refers to SAP's Web Application Server (Web AS), which is the basis for SAP applications. Web AS, which may be independent of the database and operating system 230, includes a J2EE engine 226 in combination with an already present ABAP engine or instance 228 to further enhance the application platform 208. The architecture 200 further includes a composite application framework 232 to provide various open interfaces (APIs) and a lifecycle management 234, which is an extension of the previous Transport Management System (TMS). As illustrated, the architecture 200 further provides communication with Microsoft NET 236, International Business Machine® (IBM) WebSphere™ 238, and the like 240.
The Web AS 320 having the ABAP engine 302 is further enhanced by including a J2EE engine 304. The J2EE engine 304 is in communication with the ABAP engine 302 via a fast Remote Function Call (RFC) connection 306. The two engines 302-304 are further in communication with an Internet Communication Manger (ICM) 308. The ICM 308 is provided for handling and distributing queries (e.g., Internet queries) to various individual components of the architecture 300. The architecture 300 further supports a browser 310, such as Microsoft Internet Explorer, Netscape Navigator, and other modified variations of mobile end devices, such as personal digital assistants (PDAs), pocket computers, smart cell phones, other hybrid devices, and the like. The Web AS 320 also supports various protocols and standards 312, such as HyperText Markup Language (HTML), eXtensible Markup Language (XML), Wireless Markup Language (WML), HyperText Transport Protocol (HTTP(S)), Simple Mail Transfer Protocol (SMTP), Web Distributed Authority and Versioning (WebDAV), Simple Object Access Protocol (SOAP), Single Sign-On (SSO), Secure Sockets Layer (SSL), X.509, Unicode, and the like.
At the presentation layer 410, the clients are illustrated as workstations or terminals 412-416 that are used to collect and gather user input and send it to the application layer 420 via a network connection. The network connection may be a wired or wireless connection to a LAN, a Wide Area Network (WAN), a Metropolitan Area Network (MAN), an intranet, and/or the Internet. The terminals 412-416 include personal computers, notebook computers, personal digital assistants, telephones, and the like. In one embodiment in which the network connection connects to the Internet, one or more of the user terminals 412-416 may include a Web browser (e.g., Internet Explorer or Netscape Navigator) to interface with the Internet.
The presentation layer 410 allows the end user to interact with the relevant application using a GUI, such as the SAP GUI, which is a universal client widely used for accessing SAP R/3 or mySAP functions. The GUI works as a browser and offers easy access to various SAP functions, such as application transactions, reports, and system administration functions. The SAP GUI, for example, is available in three different formats, each of which having its own unique selling point and is suited to a particular user. The three formats include SAP GUI for Windows®, SAP GUI for HTML, and SAP GUI for Java™.
The presentation layer 410 may also includes various management applications, such as a Java Management Extension (JMX)-compliant management application, a JMX manager, and/or a proprietary management application. The management applications include one or more graphical management applications, such as a visual administrator, operating to, for example, retrieve and display information received from the application layer 420 and/or the database layer 430. The visual administrator includes a monitor viewer to display such and other information. The monitor viewer includes a GUI-based or Web-based monitor viewer. Management applications include third party tools, such as file systems, to store information.
The application layer 420 includes various application servers and computing devices to perform data processing. The application layer 420 includes a dispatcher 422, which refers to the central process on the application layer 420 for processing transactions. For example, the dispatcher 422 is used to distribute the request load to individual work processes 424-428, organize communication between the work processes 424-428, and handle connection to the presentation layer 410. For example, when a user makes processing entries from his computer using the menu on the presentation layer 410, the entries are converted into a special format (e.g., GUI protocol) and forwarded to the dispatcher 422. The dispatcher 422 then places this request in a dispatcher queue. The queue is then used to find free work processes 424-428 that carry out the processing. The application layer 420 may be implemented in accordance with J2EE v1.3, final release Sep. 24, 2001, published on Jul. 18, 2002 (the J2EE Standard). An update of J2EE v1.3 was recently released, on Nov. 24, 2003, as J2EE v1.4. The management techniques described herein are used to manage resources within a “cluster” of server nodes. An exemplary cluster architecture is described below with respect to
The database layer 430 is used to optimize the data access without being dependent on the underlying database and the operating system. The database independence is achieved using open standards, such as Open SQL and Java Database Connectivity (JDC). The presentation layer 410 is where the user interacts with the relevant application, which is then executed at the application layer 420, while the data persistence 432-436 is managed at the database layer 430. The database layer 430 may include one or more database management systems (DBMS) and data sources. Furthermore, the database layer 430 is compatible with both the ABAP and J2EE environments.
The database layer 430 may include one or more database servers, EJB servers, old systems, and my SAP components. The clients at the presentation layer 410 may access one or more of the applications via standalone Java programs and programs that help access an application via, for example, using Internet Inter-Object Request Broker Protocol (IIOP)/Common Object Request Broker Architecture (COBRA) written using any number of programming languages (e.g., −C, C, and C++).
The J2EE environment may also include various J2EE containers that are associated with various J2EE services and APIs, which include Java Naming Directory Interface (JNDI), Java Database Connectivity (JDBC), J2EE connector Architecture (JCA), Remote Invocation (RMI), Java Transaction API (JTA), Java Transaction Service (JTS), Java Message Service (JMS), Java Mail, Java Cryptography Architecture (JCA), Java Cryptography Extension (JCE), and Java Authentication and Authorization Service (JAAS). The J2EE services further include EJB_service, servlet_JSP, application client_service, connector_service to provide (J2EE containers, namely) EJB containers, Web containers, application client containers, and connector containers, respectively.
A process 502-506 refers to a task being run by a computer, which is often executed simultaneously with several other tasks. Many of the processes 502-506 exist simultaneously with each of them taking turns on the central processing unit (CPU). Typically, the processes 502-506 include operating system (OS) processes that are embedded in the operating system. The processes 502-506 consume CPU time as opposed to the memory 510-514 that takes up space. This is typically the case for both the processes that are managed by the operating system and those processes that are defined by process calculi. The processes 502-506 further include specialized processes, such as ABAP work processes and J2EE worker nodes.
The operating system works to keep the processes 502-506 separated and allocate the resources to help eliminate the potential interferences of the processes 502-506 with each other when being executed simultaneously. Such potential interferences can cause system failures. Further, the operating system may also provide mechanisms for inter-process communication to enable processes to interact in safe and predictable manner. Typically, an OS process 502-506 consists of memory (e.g., a region of virtual memory), which contains executable code or task-specific data, operating system resources that are allocated to each of the processes which include file descriptor (for UNIX) and handles (for Windows), security attributes (e.g., process owner and the set of permissions), and the processor state (e.g., content of registers, physical memory addresses), which is stored in the actual registers when the process is executing.
The ABAP work processes and the J2EE worker nodes which are OS processes 502-506 are considered specialized processes that contain the attributes and behavior of the typical OS process and are created, scheduled, and maintained by the operating system. For example, the ABAP work processes are specialized in that they are used to execute the ABAP-based transactions, and the J2EE worker nodes are specialized in that they are used to execute the Java-based transactions.
Having assigned individualized memory 510-514 to each of the processes 502-506 provides a relatively inefficient computing, which lacks robustness as the processes 502-506 do not communicate with each other and have to access the local memory 510-514 for information or data. Furthermore, such network-based communication using various network connections 554-558 also causes the data processing transactions to be time-consuming, unreliable due to network errors, and less secure. For example, a typical data processing transaction may include retrieving of the data from one local memory 510-514, flowing of the data through various protocols (e.g., Transmission Control Protocol (TCP), User Datagram Protocol (UDP)), addresses (e.g., Internet Protocol (IP) address) and operating systems, before reaching its destination at another local memory 510-514.
The processes 602-606 refer to tasks embedded in the operating system. For example, each time a client initiates a program or a document (e.g., opening Microsoft Word®), a request is placed with the operating system regarding commencing the task of opening the document for the client. Several of such processes 602-606 can be performed simultaneously in the CPU by taking turns. Typically, an operating system provides the isolation of such processes 602-606, so they are less likely to interfere with each other, such as when there is a crashed process, such as process 602, none of the other processes, such as processes 604-606, are affected by it and so the potential system failure is avoided. For example, the operating system can increase isolation and robustness by allocating one process 602-606 for each user session, and running a VM for that user session within the allocated process 602-606. However, in some situations (e.g., when there are a large number of user sessions), such operating system scheduling and allocation can add to the system overhead and consume valuable resources, such as time and space.
The processes 602-606 may contain some memory (e.g., a region of virtual memory for suspended processes which contains executable code or task-specific data), operating system resources that are allocated to such processes 602-606 (such as file descriptors, when referring to UNIX, and handles, when referring to Windows), security attributes, such as process owner and the process' set of permissions, and the processor state, such as the content of registers, physical memory addresses, etc.
Various enterprise servers and other large servers are considered request processing engines for processing large numbers of small user requests associated with user sessions. The user requests lead to the creation of processes 602-606, which refer to processing of such user requests. The processing of the requests usually involves the running of a business code (e.g., Java servlets or EJBs) in a runtime system (e.g., a Java virtual machine (JVM)) executing on a server. In such a server, scalability can be achieved by using multiple threads, such as a multi-threaded VM, to process requests corresponding to a number of user sessions.
In one embodiment, the shared memory 624 can provide a common access and a buffer for the process-attachable VMs, the OS processes 602-606 including ABAP work processes and J2EE worker nodes, as well as dispatcher processes. It is to be noted that the ABAP work processes at the ABAP engine are considered specialized processes that are used for processing the OS processes 602-606 with specialized functionality. The work processes have the attributes and behavior that are also common with the OS processes 602-606 and they may be created, scheduled, and maintained by the operating system. For example, the ABAP work processes are to execute ABAP transactions, while the J2EE worker nodes, also regarded as specialized processes having similar attributes as the processes 602-606, are to execute the Java code.
Having introduced the FCA 622 to the architecture 600 facilitates an executable program (e.g., a program running on an OS process 602-606 executing the code) to use the FCA functionalities by binding the FCA library at the time of development and by calling the FCA-API in the programming language (e.g., C or Java). For example, at runtime, the executable program operates as a process 602-606 in the operating system, such as when a program (e.g., MS Word or Excel) is started several times, which creates several OS processes 602-606 associated with one program that are performed using the FCA functionalities. In one embodiment, the FCA 622 may remain independent of a particular programming language (e.g., ABAP or Java) or a particular operating system (e.g., UNIX or Windows). The FCA functionalities (e.g., ABAP statements, transactions, input/output processing, etc.) may be achieved by coding such functionalities in the program. Stated differently, the program, when running, is executed as an OS process 602-606 and as such it performs various tasks, such as reading/writing data, processing data, and accessing the FCA functionalities.
Although not illustrated here, a dispatcher (e.g., ABAP dispatcher) could serve as a central process on the application layer for processing transactions. For example, the ABAP dispatcher facilitates the starting of the ABAP work processes, monitoring of the status of the work processes, restarting a work process in case of a crash, communicating with the GUI, dispatching requests to the ABAP work processes based on the availability of such work processes, and communicating with the message server. In one embodiment, the dispatcher may use the FCA-based shared memory 624 to communicate with the work processes, but the FCA 622 alone may not necessarily replace the dispatcher. However, the functionalities of the dispatcher may be moved to other components and processes, such as to the Internet Communication Manger (ICM) (not shown) to perform one or more of the dispatcher-related tasks. In one embodiment, this can be performed by providing a code in the program, which when running on an OS process 602-606, can execute the code. Also, on the ABAP side, the dispatcher may still remain to provide communication with the GUI.
On the J2EE side, in one embodiment, the functionality of the J2EE dispatcher (not shown) may be moved to the ICM. The moving of the J2EE dispatcher functionalities to the ICM provides increased robustness, scalability, and a simple architecture with a single access point. In another embodiment, it is not required that the J2EE dispatcher be removed when using the FCA-based architecture 600 and that the FCA 622 can also work with the J2EE dispatcher to perform various tasks. In an alternative embodiment, with regard to dispatching various requests, neither the ABAP dispatcher nor the J2EE dispatcher may be needed, because the user requests can be serially assigned to the available ABAP work processes and J2EE worker nodes. For example, each ABAP work process could maintain a request queue for various requests at the shared memory 624 and attach the VM of the user session corresponding to the request at the front of the request queue to process the next request.
In one embodiment, having the shared memory 624 helps eliminate the necessity for local communication memory or individually dispersed memory for performing processes 602-606 and for communicating data. Stated differently, the shared memory 624, as opposed to a local memory using a network connection, is used to create a buffer (e.g., for receiving and transmitting data) for various processes 602-606. For example, once a request to perform a particular task is received at the server from a client/user session, a process 602-606 to be performed is initiated as the request is created. A request queue is created at the shared memory 624 and the recently-created request is then placed in the request queue. In one embodiment, the dispatcher then determines the availability of various work processes and, based on such availability, assigns the request to the available work process to handle. The work process performs the corresponding process 602-606 to satisfy the client request. The satisfying of the request may include performing the requested task and providing the requested information or response data back to the client via the shared memory 624. In another embodiment, if the dispatcher is not used, the ICM may possess the functionalities of the dispatcher and assign the request to, for example, the available ABAP work process or J2EE worker node. The ABAP-related requests are sent to the ABAP work processes and the Java-related requests are sent to the J2EE worker nodes. Having the shared memory 624 provided by the FCA 622 not only allows a copy-free transmission of the data, but also eliminates the potential of the data being lost due to connection or network failures. Furthermore, using a single shared memory 624 allows the various tasks (e.g., OS processes 602-606) to run on a single local host, which in turn, provides a secure transmission of data. In one embodiment, the shared memory 624 includes memory pipes that are used bi-directionally and are created at startup along with initialization of the FCA 622.
In one embodiment, a block of the shared memory 624 may be set aside to generate request queues with each request queue having one or more requests to be performed. In one embodiment, the work processes and worker nodes may have direct access to this block of the shared memory or portion of the block may be mapped to the address space of the selected work processes and worker nodes.
In one embodiment, the architecture 600 employs FCA handles (not shown) as communication end-points. The handles are regarded as an entity at the FCA 622 level for providing communication. Although the handles are not sockets, they act socket-like. Having the shared memory 624 reduces administrative costs, while increasing consistency and easing communication between various processes 602-606. Various entities at the shared memory 624 may include data, datagrams, application update information, strings, constants, variable, objects that are instances for a class, runtime representations of a class, and classloaders that are used to load class runtime representatives.
The shared memory 724 includes memory pipes, which are used bi-directionally, to provide bi-directional communication between various components of the architecture 700 that include the ABAP instance 704 and the J2EE instance 706 and their work processes 708-712 and worker nodes 714-718, respectively, the ICM 720, and other third-party applications 722. In one embodiment, having the shared memory 724 eliminates the necessity for the J2EE instance 706 to communicate with the ICM 702, and ultimately the client, via the TCP/IP connection. Instead, the J2EE instance 706 and the ABAP instance 704 are integrated such that both instances 704-706 are in communication with the ICM 720 via the shared memory 724. Further, the J2EE instance 706 is no longer required to have a dispatcher to dispatch client requests to various J2EE-based worker nodes 714-718. In one embodiment, the dispatcher-related tasks may be performed at the ICM 720 and, in another embodiment, the dispatcher may still be maintained and used in communication with the J2EE instance 706.
In one embodiment, the FCA 702 is used to provide an integration point for the ABAP and J2EE instances 704-706, which allows the J2EE worker nodes 714-718 and the ABAP work processes 708-712 to have access to the same centralized shared memory 724. Stated differently, not only the ABAP instance 704 and its work processes 708-712 having access to the FCA-based shared memory 724, but also the J2EE instance 706 and its worker nodes 714-718 have access to the same shared memory 724, which allows for direct bi-directional communication between various components of the architecture 700, including the work processes 708-712 and the worker nodes 714-718. Having access to the common shared memory 724 eliminates the need for associating individualized local communication memory for each of the work processes 708-712 and worker nodes 714-718 and the need for distributing the memory to various components of the architecture 700. Furthermore, the FCA-based shared memory 724 provides a common or centralized memory for each of the components to access, which eliminates the need for individualized/localized cache use for communicating entities (e.g., placing requests, updating data, retrieving responses) between components.
In one embodiment, the FCA 702 is used to provide a common API to facilitate the common access to the shared memory 724 and to provide direct bi-directional communication between various components of the architecture 700. In one embodiment, the shared memory 724 includes memory pipes that are used in a bi-directional fashion to facilitate the bi-directional communication between, for example, the ICM 720 and the ABAP and J2EE instances 704-706. The use of the shared memory 724 results in a cost-effective, efficient, fast, robust, and copy-free communication of entities between various components of the architecture 700.
In one embodiment, the ICM 720 is used to facilitate communication between the architecture 700 and the outside world by providing a browser or browser-like access to the user. The Internet protocols supported by the ICM 720 are provided as plug-ins for other standard protocols (e.g., HTTP, SMTP). For example, in a server role, the ICM 720 processes requests from the Internet that are received from the client via a Uniform Resource Locator (URL) with the server/port combination that the ICM 720 listens. The ICM 720 then invokes the local handler responsible for processing these requests, based on the URL. Applications (e.g., Business Server Page (BSP)) needing an ABAP context are transferred to the ABAP work processes 708-712, while Java requests are transferred to the J2EE instance 706 to be processed by the J2EE worker nodes 714-718. In one embodiment, the transfer of the requests between the ICM 720 and the ABAP instance 704 is conducted via a dispatcher, which also serves as a load balancer and a point for providing connection to a GUI, such as the SAP GUI. On the J2EE side, the dispatcher may not be present.
The ICM 720 may include a central request queue for requests that are processed on worker threads. Various time-consuming operations (e.g., accept, SSL handshake, read, write, handshake, and close) are triggered through a request in the ICM request queue, which may not be protocol-specific. The queues in the shared memory 724 include request queues for each of the work processes 708-712 and worker nodes 714-718. The number of entries in the request queues at the shared memory 724 provides an indication of the load situation of the server. The queues in shared memory 724 may also include other relevant information, such as information to help with FCA Queue Monitoring (FQM). The values may include the name of the queue (set at startup), current number of requests in the queue (set by a dedicated process), peak number of requests (maintained by FCA), maximum number of requests (fixed value that can be set at startup), last insert (maintained by FCA), and last remove (maintained by FCA).
In one embodiment, once the connection is established 814, the FCA client 804 sends 816 a request to the server 802. The server 802 receives the request having request data 818 from the client 804. The request is then processed at the server 802 using various entities and the server 802 then sends the response data 820 in response to the request from the client 804 to the client 804. The client 804 receives the response data 822. The FCA connection is then closed 824 when it is not longer needed.
At decision block 916, a determination is made as to whether more requests are to be received. If yes, the process continues with processing block 910. If not, the connection is closed at termination block 918.
In one embodiment, the request may be received at the shared memory via the ICM, which may include additional request queues to properly hold, maintain, and distribute the incoming client requests to the shared memory. The request is then assigned to an entity or component, such as an available work process, to process the request at processing block 1008. The assigning of the request for processing includes determining whether the request is ABAP-based or Java-based. For example, an ABAP-based process request is assigned to an available ABAP work process at the ABAP instance, while the Java-based process request is assigned to an available J2EE worker node at the J2EE instance. Having the FCA-based shared memory allows the ABAP and J2EE instances to have direct bi-directional communication via the shared memory.
The assigned request is then retrieved from the shared memory by the available work process or the available worker node so that the request can be satisfied at processing block 1010. The request is then processed at processing block 1012. While the request is being processed by the available work process or worker node, subsequent requests corresponding to various processes are continuously received at the shared memory and are placed in various request queues at the shared memory.
A system architecture according to one embodiment of the invention is illustrated in
The sever nodes 1114, 1116, 1118 within instance 1110 provide the business and/or presentation logic for the network applications supported by the system. Each of the sever nodes 1114, 1116, 1118 within a particular instance 1110 may be configured with a redundant set of application logic and associated data. In one embodiment, the dispatcher 1110 distributes service requests from clients to one or more of the sever nodes 1114, 1116, 1118 based on the load on each of the servers. For example, in one embodiment, the dispatcher 1110 implements a round-robin policy of distributing service requests.
The sever nodes 1114, 1116, 1118 may be Java 2 Enterprise Edition (“J2EE”) sever nodes which support Enterprise Java Bean (“EJB”) components and EJB containers (at the business layer) and Servlets and Java Server Pages (“JSP”) (at the presentation layer). Of course, the embodiments of the invention described herein may be implemented in the context of various different software platforms including, by way of example, Microsoft NET platforms and/or the Advanced Business Application Programming (“ABAP”) platforms developed by SAP AG, the assignee of the present application.
In one embodiment, communication and synchronization between each of the instances 1110, 1120 is enabled via the central services instance 1100. As illustrated in
In one embodiment, the locking service 1102 disables access to (i.e., locks) certain specified portions of configuration data and/or program code stored within a central database 1130 or resources shared in the cluster by different services. The locking manager locks data on behalf of various system components which need to synchronize access to specific types of data and program code (e.g., such as the configuration managers 1144, 1154). As described in detail below, the locking service enables a distributed caching architecture for caching copies of server/dispatcher configuration data.
In one embodiment, the messaging service 1104 and the locking service 1102 are each implemented on dedicated servers. However, the messaging service 1104 and the locking service 1102 may be implemented on a single server or across multiple servers while still complying with the underlying principles of the invention.
As illustrated in
Referring now to
In one embodiment of the invention, to improve the speed at which the various servers and dispatchers access the configuration data, the configuration managers 1144, 1154 cache configuration data locally within configuration caches 1200, 1201. As such, to ensure that the configuration data within the configuration caches 1200, 1201 remains up-to-date, the configuration managers 1144, 1154 implement cache synchronization policies, as described herein.
A hard drive or other storage device 1330 may be used by the system 1300 for storing information and instructions. The storage device 1330 may include a magnetic disk or optical disc and its corresponding drive, flash memory or other nonvolatile memory, or other memory device. Such elements may be combined together or may be separate components. The system 1300 may include a read only memory (ROM) 1335 or other static storage device for storing static information and instructions for the processors 1315 through 1320.
A keyboard or other input device 1340 may be coupled to the bus 1310 for communicating information or command selections to the processors 1315 through 1320. The input device 1340 may include a keyboard, a keypad, a touch-screen and stylus, a voice-activated system, or other input device, or combinations of such devices. The computer may further include a mouse or other cursor control device 1345, which may be a mouse, a trackball, or cursor direction keys to communicate direction information and command selections to the processors and to control cursor movement on a display device. The system 1300 may include a computer display device 1350, such as a cathode ray tube (CRT), liquid crystal display (LCD), or other display technology, to display information to a user. In some environments, the display device may be a touch-screen that is also utilized as at least a part of an input device. In some environments, the computer display device 1350 may be or may include an auditory device, such as a speaker for providing auditory information.
A communication device 1350 may also be coupled to the bus 1310. The communication device 1350 may include a modem, a transceiver, a wireless modem, or other interface device. The system 1300 may be linked to a network or to other device using via an interface 1355, which may include links to the Internet, a local area network, or another environment. The system 1300 may comprise a server that connects to multiple devices. In one embodiment the system 1300 comprises a Java® compatible server that is connected to user devices and to external resources.
While the machine-readable medium 1330 is illustrated in an exemplary embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine of the system 1300 and that causes the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
Furthermore, it is appreciated that a lesser or more equipped computer system than the example described above may be desirable for certain implementations. Therefore, the configuration of system 1300 may vary from implementation to implementation depending upon numerous factors, such as price constraints, performance requirements, technological improvements, and/or other circumstances.
It should be noted that, while the embodiments described herein may be performed under the control of a programmed processor, such as processors 202-206, in alternative embodiments, the embodiments may be fully or partially implemented by any programmable or hardcoded logic, such as field programmable gate arrays (FPGAs), it logic, or application specific integrated circuits (ASICs). Additionally, the embodiments of the present invention may be performed by any combination of programmed general-purpose computer components and/or custom hardware components. Therefore, nothing disclosed herein should be construed as limiting the various embodiments of the present invention to a particular embodiment wherein the recited embodiments may be performed by a specific combination of hardware components.
It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention.
Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.
While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive, and that the embodiments of the present invention are not to be limited to specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art upon studying this disclosure.