IBM WebSphere eXtreme Scale V7.0 IBM WebSphere eXtreme Scale V7.0 Overview This presentation will cover WebSphere® eXtreme Scale V7.0, a high performance caching platform for conducting transaction processing, formerly known as Extended Deployment DataGrid or ObjectGrid. WebSphere eXtreme Scale overview WebSphere eXtreme Scale overview WebSphere eXtreme Scale operates as an in-memory data grid that dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers Performs massive volumes of transaction processing with high efficiency and linear scalability Provides qualities of service such as Transactional integrity High availability Predictable response times WebSphere eXtreme Scale operates as an in-memory data grid that dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers. The product enables data-intensive business applications to process massive volumes of transactions with high efficiency and linear scalability. It provides transactional integrity and transparent failover to ensure high availability, high reliability, and predictable response times. WebSphere eXtreme Scale overview WebSphere eXtreme Scale overview Can be used as a powerful distributed cache to speed application access to data Can be backed by hardened storage Cache loader interface enables automatic storage and retrieval of data according to user preferences to the technology of your choice (like a database) Can automatically replicate data either synchronously or asynchronously to ensure data availability and lower management burden Securable using Java™ authentication and authorization service (JAAS) API WebSphere eXtreme Scale can be used as a powerful distributed cache with data stored in memory to speed application access to data. The cache loader interface enables you to implement a class that uses the hardened storage technology of your choice, such as a database, as a backing store for the cache. The cache loader can also be used to retrieve data, so that all data does not have to be in-memory at one time. WebSphere eXtreme Scale can ensure data availability and lower the management burden with automatic replication of data. Additionally, an eXtreme Scale grid instance is securable using the standard Java Authentication and Authorization Service API. Scalability Scalability eXtreme Scale can grow to hold hundreds of JVMs of data for very large data sets Scales nearly linearly with additional hardware Supports thousands of concurrent clients Supports 32-bit or 64-bit JVMs eXtreme Scale clusters can be replicated and partitioned for fault-tolerance and high performance Cluster members communicate with each other using an ultra-high speed pub sub system High performance and low processor overhead An eXtreme Scale grid is highly scalable, supporting a local cache within a single Java virtual machine, all the way up to a fully replicated cache distributed across numerous cache servers. As data volumes grow or as transaction volume increases, additional servers can be added to store the additional data and ensure consistent application access. eXtreme Scale technology can be spread across clusters throughout an entire enterprise to guarantee high availability. If a primary server fails, a replica is promoted to primary automatically to handle fault tolerance and ensure high performance. To facilitate this, eXtreme Scale cluster members communicate with each other using a highly optimized, dedicated publish and subscribe messaging system. Deprecated features Deprecated features Partitioning facility Entire component Libraries not installed by default The partitioning facility is a set of programming APIs that allow Java Enterprise Edition applications to support asymmetric clustering. The application specifies a set of named partitions to split data access across a set of servers. These partitions must be manually placed by using high availability manager policies. This manual placement can become a burden if a large number of partitions are needed. WebSphere eXtreme Scale provides similar capabilities but is easier to configure, provides better failover support, and scales better than the partitioning facility. Therefore, this feature is being deprecated in WebSphere eXtreme Scale V7.0. ObjectGrid clients and servers ObjectGrid clients and servers An ObjectGrid server Contains grid containers which host the cache (stored in BackingMaps) Is a JVM running on a particular host and port that Listens on a port for client requests Can communicate with other ObjectGrid servers to create a self-configuring grid An ObjectGrid client Must connect to an ObjectGrid server to perform various operations, such as create, retrieve, update and delete the objects in the grid Contains an ObjectMap and can contain a “near-cache” copy of a BackingMap There are two components that can contain BackingMaps within the eXtreme Scale framework, the ObjectGrid server and the ObjectGrid client. The ObjectGrid server, contains grid containers which host the cache, stored in BackingMaps. The grid server is a JVM running on a particular host and port that listens for client requests and can communicate with other ObjectGrid servers and catalog servers to maintain a self-configuring, self-healing eXtreme Scale grid. The ObjectGrid client, or grid client, will connect to a grid server to perform operations such as create, retrieve, update and delete to the objects in the eXtreme Scale grid within the scope of a single transaction. The client contains an ObjectMap and can contain a copy of a BackingMap. The grid server BackingMap is always shared between clients, while the client-side BackingMap, or near-cache, is shared only between threads of the grid client. The terms “grid server” and “ObjectGrid server” can be used interchangeably. z/OS eXtreme Scale support z/OS eXtreme Scale support eXtreme Scale clients are supported on the z/OS® platform Clients can contain a “near-cache” copy of the data z/OS applications must connect to an eXtreme Scale server running on a distributed platform to perform various operations, such as create, retrieve, update, or delete, to the objects in the grid WebSphere eXtreme Scale V7.0 provides client support access on the z/OS platform. Clients might contain a near-cache copy of the BackingMap. However, an application deployed to z/OS will require access to an eXtreme Scale server. The z/OS eXtreme Scale client must connect to an off-platform eXtreme Scale server, such as Linux®, in order to perform various operations to objects in the grid. Working with WebSphere eXtreme Scale Working with WebSphere eXtreme Scale Transactional support Operations take place within the scope of a transaction for consistency 1-phase commit supported Customizable cache life cycle features Declaration, configuration, size management, cache loading, and eviction policies ObjectGrid query API Flexible query engine for retrieving Entities and Java objects As more and more data is stored in the grid, WebSphere eXtreme Scale provides a high performance, transactional cache facility that will allow you to work with ease with your data. It is highly customizable. For example, interfaces are provided for implementing custom cache loading, size management, and invalidation schemes. WebSphere eXteme Scale also provides powerful query mechanisms for retrieving objects from the cache using non-key attributes. The ObjectGrid query API allows select type queries over an Entity or Object-based schema using the ObjectGrid query language. HTTP session persistence HTTP session persistence HTTP Sessions can be replicated across servers using eXtreme Scale A servlet filter that enables session replication can be inserted into any Web application Provides a session persistence approach that is independent of the WebSphere cell infrastructure Older versions of WebSphere products can use eXtreme Scale as an upgraded session persistence mechanism Non-WebSphere servers (such as Geronimo or JBoss) can also use this servlet filter WebSphere eXtreme Scale can be used to persist and set up your HTTP session data. Basically, you can override the default session manager in the base application server to provide HTTP session management capabilities for an associated application. The eXtreme Scale session manager can create HTTP sessions and manage the life cycle of HTTP sessions that belong to the application. This life cycle management includes the invalidation of sessions based on timeout or an explicit servlet or JavaServer Pages (JSP) call and the invocation of session listeners that are associated with the session or the Web application. WebSphere eXtreme Scale example WebSphere Application Server servlet JVM Heap eXtreme Scale grid “plants” BackingMap WebSphere eXtreme Scale example Client A Client A – get flowers Servlet – begins the session Servlet – attempts to get flowers ObjectMap - returns null (cache miss) Servlet – retrieves flowers from DB Servlet – inserts flowers into cache Servlet – commits session Servlet – returns flowers to Client A 9+ Client B – get flowers … Database 5 grid session A “plants” ObjectMap 2 1 8 Client B If Client B now does a get for flowers, the get will result in a cache hit 3 3a 4 flowers 7 6 Client B grid session B “plants” ObjectMap 9 10 11 If Client B now does a get for flowers, the get will result in a cache hit 12 13 14 This example shows an application that requests an object that is not in the grid. The object is retrieved and then inserted in the grid, so future requests for that object can be fulfilled directly from the eXtreme Scale grid. Client A sends a request for the flowers object to the servlet. The eXtreme Scale grid and BackingMap have already been created, so when a user initially interacts with the grid a session is established. In this case, the servlet begins a session for Client A. The servlet then attempts to “get” the flowers object from the eXtreme Scale grid. As this is the first time a request for the flowers object has been made, it will result in a miss because it is not yet present in the grid. So, the servlet will retrieve the flowers object from a back end database and use an “insert” to place the object into the BackingMap in the grid. At this point, the session’s ObjectMap is committed to the BackingMap and the flowers object is returned to Client A. A similar sequence will occur for Client B when it requests the flowers object, only this time the object already resides in the BackingMap, so this request is fulfilled directly from the eXtreme Scale cache. Working with eXtreme Scale data Working with eXtreme Scale data An eXtreme Scale grid contains one or more map-like objects (ObjectMaps) Interface similar to java.util.Map ObjectMaps support all of the expected map methods put(), get(), insert(), update(), and so on. Objects are stored as map entries (key value pairs) Can be entered into the map by the application Can be loaded from an external source using a custom loader class Can be indexed on key or attribute values Java objects are stored in an eXtreme Scale grid using key value pairs within map objects called ObjectMaps. Data can be put into and retrieved from an ObjectMap within the scope of a transaction using all of the typical map-like methods through an interface similar to java.util.Map. The map can be populated directly by the application, or it can be loaded from a back-end store by implementing a custom cache loader class. eXtreme Scale configuration eXtreme Scale configuration Section This section will cover basic eXtreme Scale configuration. Configuration options Configuration options eXtreme Scale client instances can be configured programmatically or using Extensible Markup Language (XML) files You can configure the client to disable the near cache XML files define the Java implementations that should be used and how they are associated To create an ObjectGrid client using an XML file: ObjectGridManager myObjectGridManager = ObjectGridManagerFactory.ObjectGridManager(); ClientClusterContext clientClusterContext = myObjectGridManager.connect(“MyServer1.company.com:2809”, null, new URL(“file:xml/newGridClient.xml”)); To configure an eXtreme Scale client, you must first create an ObjectGrid instance within your application. The instance can be configured programmatically, or created based on configuration data stored in a descriptor XML file. The client near cache is enabled by default when locking is configured as optimistic or none and it can not be used when configured as pessimistic. However, as part of the client configuration, the near cache can be disabled. The code snippet shown here illustrates how to create the “newGrid” ObjectGrid client. You would pass the ObjectGrid XML file, “newGridClient.xml” as a URL to one of the connect methods on the ObjectGridManager. Note that ObjectGrid is still used when referring to an eXtreme Scale grid object. Overriding the settings Overriding the settings By default, the ObjectGrid client has the same settings as the ObjectGrid server To alter the settings, you must create an ObjectGrid XML file or an ObjectGridConfiguration object that is similar in structure to the server-side eXtreme Scale and override the settings You can override these plug-ins on a client: ObjectGrid plug-ins TransactionCallback plug-in ObjectGridEventListener plug-in BackingMap plug-ins Evictor plug-in MapEventListener plug-in numberOfBuckets plug-in ttlEvictorType attribute When you configure an ObjectGrid client, by default it has the same settings as the ObjectGrid server. You must create an ObjectGrid XML file or an ObjectGridConfiguration object that has similar structure to the ObjectGrid server, then override the plug-in settings as needed in order to meet specific client requirements. eXtreme Scale topology with z/OS eXtreme Scale topology with z/OS Section There are many different ways to integrate eXtreme Scale into your environment. This section will discuss how to include z/OS clients into your topology. Distributed cache topology with z/OS Distributed cache topology with z/OS eXtreme Scale supports complex topologies, including highly available distributed, partitioned and replicated cache which can scale to thousands of containers containing terabytes of data. Distributed eXtreme Scale caches offer increased performance, availability and scalability. Local and distributed eXtreme Scale topologies both provide the same application programming model for interacting with the cache. This distributed cache topology shows z/OS application servers hosting the ObjectGrid clients. The WebSphere eXtreme Scale for z/OS client will begin its access to the grid by obtaining a routing table from the catalog service which enables the client to locate the primary partition shard and object. Once the client knows which server contains the needed data, it can communicate with that ObjectGrid server to access the data from the ObjectGrid. Detailed distributed cache topology with z/OS Detailed distributed cache topology with z/OS Database Java Virtual Machine z/OS Application ObjectGrid Client Thread Thread Thread JVM Linux ObjectGrid Cache Java Virtual Machine z/OS Application ObjectGrid Client Thread JVM Linux ObjectGrid Cache Thread Thread Partition In this distributed cache topology, you can see that the application logic is running on application servers separate from the eXtreme Scale grid servers. The application servers are running on the z/OS platform and each host a grid client which can communicate with the grid servers to access data from the far cache. The data stored in the ObjectGrid is spread across all the Java Virtual Machines running on other platforms, such as Windows® or Linux, that have WebSphere eXtreme Scale installed and configured. Summary Summary Section This section will provide a summary of this presentation. Summary Summary WebSphere eXtreme Scale provides a high performance, scalable cache system capable of performing massive volumes of transaction processing It operates as an in-memory data grid that dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers Only eXtreme Scale clients are supported on the z/OS platform WebSphere eXtreme Scale provides a high-performance, scalable, transactional cache technology. It operates as an in-memory data grid that can dynamically cache, partition, replicate, and manage application data and business logic across multiple servers. Currently, WebSphere eXtreme Scale V7.0 provides only client support access on the z/OS platform. The z/OS eXtreme Scale client must connect to an off-platform eXtreme Scale server in order to interact with the eXtreme Scale grid. Overall, the eXtreme Scale cache is designed to be highly extensible, so that you can implement a cache system that meets the needs of your specific environment. Feedback Feedback Your feedback is valuable You can help improve the quality of IBM Education Assistant content to better meet your needs by providing feedback. Did you find this module useful? Did it help you solve a problem or answer a question? Do you have suggestions for improvements? Click to send e-mail feedback: mailto:iea@us.ibm.com?subject=Feedback_about_WXS70z_Overview.ppt This module is also available in PDF format at: ../WXS70z_Overview.pdf You can help improve the quality of IBM Education Assistant content by providing feedback. Trademarks