Nati Shalom's Blog

Is Your Data Really Secured?

Security has always been one of those topics that we as developers or architects hate to deal with. Our ideal world would be that security is dealt with at some higher level in our data-center, and that we don't need to think about it. It turns out that some of the most recent frauds can be caused by someone from within our own organization. In this specific fraud case, the cost to SocGen was $7.7b.  There was nothing specific in this incident that was a direct result of an application security failure, but it does force us to examine more carefully some of the current assumptions about security. In this post I focus on some of the potential security vulnerability that we may be exposed to as a result of using data-grid and caching more and more within our organization. 

Why Do We Need a Secured Data-Grid?

We add the data-grid/caching layer as a front end to the database to address the database scalability limitation. One of the common assumptions in this sort of model, is that the caching layer is an embedded part of a particular application. In other words, the caching layer can only be accessed by a specific application. Based on that assumption, it is fair to assume that it is the application's responsibility from a security perspective, to control access to its caching layer. Therefore, security was not generally considered to be a critical aspect of many of the existing caching solutions.

However, there are two things that change that assumption:

• Caching becomes a shared service (just like databases of today), that is shared by more than one application. SOA-based applications are a good example of this. SaaS-based applications impose an even bigger challenge in this regard.
• Virtualization and the drive for better utilization, forces us to think of a more efficient deployment model through sharing of resources. Having a dedicated in-memory cluster per application can be a fairly inefficient model, but on the other hand, running in a shared environment requires a high degree of isolation support by the data-grid service.

Security assumptions and constraints change significantly when you move from a cluster dedicated to one application, to a cluster shared between several applications. It is no longer enough to assume that the application is responsible for granting access to its embedded middleware components. In this case, multiple applications which share the same data, must have the right level of isolation and access. Securing the shared middleware resources is the key to achieving this level of isolation and control.

In the next section I describe the specific attributes that a secured data-grid must support.

Securing Your Shared Data-Grid/Caching Layer

1. Granting Access Based on Roles and Content

Imagine the following cases:

• Several applications can access the same data-grid service, and be granted different permissions to view each data item, based on the content of the data.
• Different parts of the same application (e.g. purchasing module vs. sales module) may be granted access to different accounts, even though all the account data is stored in the same shared data-grid.
• One part of an application can be granted read/write access, while another part of an application can be granted read-only access to the same data.

This scenario is very similar to what we expect from most databases today. A user can be granted access (authentication) through user-name/password authentication, and they can be granted read/write access (authorization) to the shared data. Providing such a level of control is fairly basic and core to any secured data-grid. However, there are cases where we would want to grant access to different parts of organizations, or where customers need to have different privileges for different parts of the shared data. For example, in a call center application, we might have a shared call center service that serves different departments in our organization. In such a case, we would want callers of certain departments to see only the contacts that belong to them, and not be granted privileges to see or have access to contacts that belong to other departments. In that case we would need to provide fine-grained authorization, based on the actual content.

2. Ensuring Isolation in a Multi–Tenant Environment

There are many cases where we do not want to share the same data-grid between different groups of applications, but at the same time we do want to share the physical memory resources. A multi-tenant environment implies that we run multiple services or applications in a shared environment, but keep them logically separated, as if they were running in their own dedicated environment. That level of separation is referred to as isolation. In order to do that, we need an abstraction layer that enables us to provision our data-grid as a set of fine-grained services that can be managed independently, even if they run on the same process. Abstracting the data-grid as fine-grained services enables us to provision the data-grid services on a shared group of machines or even processes (JVM’s), and still manage them completely independently.

There are a few components that enable that level of fine-grained isolation:

• Life cycle management – each data-grid can be started or relocated, completely independently of other data-grid services, even if they run on the same process container.
• Class-loader  - each data grid contains its own class-loader to ensure that there is no class version conflict between two data-grid services.

In addition to that, there are other levels of isolation, such as ‘zones’ where we can ensure that certain data-grid services never share the same process or even the same machine. At the top level, we can assign a data-grid with specific virtual machines (VM), which ensures the highest level of isolation, not just at the service level, but also at the operating and physical resources level.

Providing this level of fine-grained isolation control between data-grid services that share the same process, up to a completely separate data-grid that runs on its own virtual machine, is critical if we want to ensure best utilization on the one hand, and isolation on the other hand. Providing a limited degree of isolation determines how effectively we can share resources.

3. Transport Level Security

In most data-grid deployment, it is fair to assume that network level security is a responsibility of the data-center, not the data-grid, or even the application. There are cases where the data-grid can span across multiple firewall or data-center zones, and have a replication channel between those zones. In such cases, the replication channel can turn out to be a security loophole. The simplest approach to address this challenge, is enable replication over SSL. Using SSL can ensure that no one can “sniff” the packets that go over the wire.

The Administrative Challenge

Providing all this level of fine-grained security control and multi-tenancy can pose a huge administrative challenge. For example:

1. A super administrator needs to have full access to all data-grid services

2. An application administrator only needs to be granted access to data-grid services that belong to a particular application.

3. Operational managers need to be granted monitoring (read-only) access, to view how the system is behaving, but don't need to be granted access to change the data-grid topology or configuration.

These are only few of the challenges that we have to deal with, once we move from a dedicated data-grid to a shared data-grid. This basically means that we can’t assume that all administration operations to our data-grid are the same.  We need to treat operation guys differently then we deal with application managers, and they all need to have visibility and some level of control to our shared services. That means that we have to rethink how to manage security when we deal with shared data-grid services.

Not Just Your Data..

The same arguments that I have mentioned here, apply not just to the data-grid, but to any part of the application middleware that is going to become a shared resource. For example, think of the messaging service, or any other part of your application that becomes a service to other applications. This implies that we need some sort of generic way to handle application security that is consistent across the layers of the application.

How Security Reduces Costs

Being able to share data-grid services between multiple applications is a great cost saver. Here is how:

1. Better utilization  - we can better utilize the machines that run our data. In other words, we reduce the total number of machines that run our data services. The fact that we use less machines to run our data-grid services means that can save all of the cost associated with it i.e. cooling, maintanance, space etc.

2. Pooling of spare resources – each data–grid needs to run some level of spare capacity. Sharing of data-grid services enables us to share that spare capacity, and therefore better utilize it amongst different applications.

3. Reduction of the amount of redundant data – one of the ways that organizations dealt with the lack of ability to share their data services effectively, was by maintaining different copies of that same data. That led to redundant copies, as well as a lot of synchronization cost associated with it. Being able to safely share the data, means that we remove a lot of that overhead, and the cost associated with it.

4. Reduced administrative overhead – the data-grid becomes just like a data-base: instead of having each application group learn how to provision it separately, and go through the cycles of tuning and sizing it separately, we now have all that knowledge and skill set managed by a shared group. This is the same way in which Amazon manages its SimpleDB, SQS and other services - we as users of those services don’t need to worry about how to provision or maintain it.

Final Words

Caching/data-grids are going through a similar evolution to databases. As with databases, we started by using caching as an embedded service to the application. Now we are in the phase where we need to be able to share the data between multiple applications, or in cases where we don’t want to share the data, we need to be able to share the resources for managing the data, while keeping a high degree of isolation. The demand for these sort of requirements becomes much more common with SOA or SaaS-based applications.

We used to think of security as a defensive move. However, security is not just about protecting our data – security can create the right level of isolation that is a main enabler for achieving better efficiency and cost savings, through sharing of resources, as I pointed out above.

As we approach the next generation of middleware and data-centers, it becomes clear that we cannot move to the next wave of virtualization and cloud computing without a strong security and isolation solution that is built-in to all layers of our application and middleware.

GigaSpaces Security as a Reference for a Secured Data-Grid:

If you are interested to learn how these challenges have been addressed specifically by GigaSpaces, you are welcome to join a technical webinar that we will be conducting on that subject. The webinar will take place on Wednesday, October 28, 2009 9:00 AM - 10:00 AM PDT

GigaSpaces based solution makes it to the finalist of Cisco Developer Contest

I was very pleased to read an email from Leonardo, who was the winner of the OpenSpaces Developer Challenge (a worldwide programming contest using the Gigaspaces application server which was held last year), saying that he is now a finalist in the Cisco developer contest. Here's a bit about him and the application he submitted:

About Leonardo

Leonardo worked for several ISPs in various roles as network administrator and java programmer for IT consulting firms, and finally as software architect in high-performance Java EE based projects. He is passionate about parallel programming, distributed computing and more recently semantic web and its applications on software engineering.

Leonardo was the winner of the OpenSpaces Developer Challenge. He enjoys reading about various technologies in the field of computer science. When he is not developing code, he prefers to spend time with family and friends, walk in the park, or watch a movie.

About the application

Resource Management Platform is a proposal to develop an event based platform that leverages AXP, Services Gateway Initiative (OSGI), Jini and JavaSpaces technologies to enable deployment of IP Multimedia Subsystem (IMS) applications based on Session Initiation Protocol (SIP); more specifically, the Call Section Control Function (CSCF) components. It will have admission control mechanisms to manage Call processing.

This solution improves infrastructure manageability for large scale IMS applications. Such a platform will potentially be useful to enable deployment of high-performance, network-based SaaS (Software as a Service) or Cloud Computing solutions at the network edge by leveraging AXP.

You can find the full details about his project here.

Leonardo's project is interesting, because it shows how you can use Space Based Architecture (SBA) for implementing a scalable Telco application and offer it as SaaS application on the cloud.

Interestingly enough, I got another email the week before from Amin Abbaspour, who presented another case study illustrating how you can build a scalable SMS service using SBA, as shown in this diagram:

 

What the two projects have in common, from an architecture perspective, is that they both represent a highly scalable Event Driven design. The unique thing about Event Driven applications is that they require a combination of messaging, data and service interaction that needs to be tightly orchestrated to meet high performance/low-latency requirements without compromising on consistency, ordering (FIFO) and reliability. This combination of requirements represent one of the hardest challenges in building scalable architectures. Trying to meet this type of challenge in the traditional way by integrating messaging system for event delivery , database or simple caching (like Memcached or TC) for data and a traditional application server for business logic is going to lead to fairly complex architecture. Trying to reach linear scalability and keeping the latency low with so many moving parts is close to impossible. This is what makes SBA such a good fit. The main difference about SBA is that it recognizes there is strong dependency between messaging, data and business logic. The key is to have one shared clustering, high availability and scalability for all three components of the architecture. This makes it possible to reduce the number of moving parts and network hops associated with each business transaction, thereby increasing reliability.

On a personal level, I was very pleased to see that the software we are developing is helping people like Leonardo and Amin to build their own carrier and put themselves in a unique spot in highly competitive market.

Good luck Leonardo and Amin!

References

• Making EDA programming simple with JeeWiz
• Cisco AXP Developer contest
• What's new in GigaSpaces XAP 7.0
• GigaSpaces on the cloud
• OpenSpaces developer portal

Simple and cost effective Enterprise-SOA with GigaSpaces and Mule

MuleSource is a rather popular open source ESB implementation. What I particularly liked about it when I first saw it is how simple it is to glue different services that are communicating in different protocols in a very simple way even if they don't comply with the same standard API.

Another thing that I like about MuleSource is its light weight and simple architecture. Unlike many other ESB implementations, Mule does not bind itself to the use of web services. In fact you can use Mule for orchestrating the flow between SAP and Siebel in the same way that you can orchestrate two POJO services collocated under the same process. This approach has made the integration with GigaSpaces possible as it has enabled us to introduce many of our innovative ideas and bring in the value of Space Based Architecture into the Enterprise SOA world. It is also a good fit with the type of customers we are engaged with in where latency and performance play an important role. The interesting thing is that thanks to the Mule connector architecture your application code does not need to “know” anything about GigaSpaces. All it "sees" is better performance and reliability. For GigaSpaces users the integration with Mule helps to connect GigaSpaces applications to the external world quite easily and leverage many of the existing sets of connectors available with Mule to plug-in those other protocols without writing additional code. We already have a few customers who chose to use GigaSpaces and Mule together and are quite happy with the results. An example of some of the feedback being received can be seen in the following post GigaSpaces and Mule= Pure Sex.

GigaSpaces and Mule ESB integration overview:

Basically there are a few components to the integration: 

• GigaSpaces connector – The GigaSpaces connector enables GigaSpaces to plug-in as an high performance transport.
• Mule server clustering – This is where GigaSpaces clustering is leveraged to enable in-memory fault tolerant solution for the Mule server itself.

The GigaSpaces Mule Connector:

The diagram below shows how services that are running within Mule can use the GigaSpaces Connector as a transport layer.

As can be seen in this diagram the services are unaware of the GigaSpaces implementation. These details are abstracted by the Mule server. The interaction is done declaratively outside of the services code. When a service receives an event it processes it and the result of that event is sent back to Mule which in return calls the GigaSpaces Connector to store that state. Other service uses the same connector to wait for that state change and once that happen that triggers the appropriate method on that service implementation and so forth.

Mule server clustering

The diagram below illustrates how Mule integrates with GigaSpaces in-memory cluster to ensure high availability and reliability.

 

In general all the Mule state (SEDA Queues in particular) as well as the application state is stored in the GigaSpaces in-memory cluster. That state is replicated synchronously to a backup instance. When the primary node fails the back--up node takes over automatically and continues to process the events from the exact point where they failed. This enables continuous high availability of the application and seamless fail-over without enforcing the user to take explicit action during that failure event and without the need to handle complex re-tries to ensure the reliability and consistency of the application after a failure event.

Announcement:

Given the positive experience both us (GigaSpaces) and the MuleSource team have had, we decided to formalize this integration. . This Wednesday (Feb 11 @ 9 AM PDT/ 12 PM EDT/ 6 PM CET) we are hosting a joint webinar in which we will unveil the details behind this new development. In this webinar Uri Cohen, GigaSpaces Product Manager, and Ken Yagen, Sr. Director of Engineering at MuleSource, will discuss the details behind this integration and use a live demonstration to illustrate how it works. This will also be a good opportunity to ask the experts more questions about this joint offering. To join this webinar make sure that you register prior to the event here

See you at the webinar!

GigaSpaces XAP 6.5/6.6 new releases

GigaSpaces 6.5 was released at the end of June, and we are now working on the 6.6 release, with the first milestone already publicly available. These are major milestones in a series of upcoming releases all aimed at strengthening our proposition as a Scale-Out App Server. Our main goal is to significantly simplify the process of achieving scalability, including scaling an EXISTING application within days and without enforcing a complete re-architecture.

I refer to this as our "Seamless Scaling" or "Simple Scaling" initiative. You can read some of the rationale behind this initiative in my previous post Can scalability be made seamless. This is a very ambitious goal, and by all means, we are not finished. In addition to the tremendous enhancements already put in place, we have a long-term roadmap that covers many aspects of the product.

The efforts we have undertaken (as well as those on our roadmap) involve enhancements to our development frameworks in Java, .Net and C++, mostly around the abstraction layer, including supporting standard APIs that enable us to inject many of our Data Grid and event-driven capabilities through annotations and configuration, with zero or minimal changes to application code.

They also involve increasing robustness, making large-scale deployments simpler to deploy and manage. Other efforts include extensive integration with popular frameworks, such as Spring and Mule, and recently we also added Web framework integration with Jetty. All this is designed to make the end-to-end scaling experience extremely simple and native. Judging by recent feedback we received, some of it publicly referenceable, it looks like we're making great strides in achieving our goal. I particularly liked the following quote by one of our existing customers Monte Paschi Group, who built a new pricing system with GigaSpaces. Their full case study is available  here. I chose the following quote from this study as it highlights some of the benefits that we don't always emphasize enough - development simplicity:

The development team is happy, too,  since the architecture has been
greatly simplified compared to the multi-layered application server system.
"We're not a software company, we're a financial company," Santini
explains. "We didn't have weeks or months to study the technology. Our
main goal was to use it to achieve our goals. GigaSpaces XAP allowed us
to do that right out of the box.

You can read the full details of the 6.5 release here. For convenience, we grouped separately the long list of features into Java,.Net and C++ categories, and provided detailed descriptions that outline the rationale and the value behind each feature.

In this post I'll try to highlight some of the important features and provide insight into our future plan.

Seamless scaling using the Service Virtualization Framework

At the application layer the most notable feature is the Service Virtualization Framework. The Service Virtualization Framework (SVF) can be seen as a major enhancement to Session Beans in EJB3 and Spring Remoting. This  framework enables you to write your business logic as a POJO and deploy the services across a cluster of machines, while providing a single client proxy that virtualizes all those instances as if they were a single server. For more details I recommend reading a new white paper covering the concept behind this framework and how it can help you simply build scalable, high-performance SOA and event-driven applications. The white paper is available here

Seamless scaling of popular development frameworks

We enhanced and expanded our integration with popular development frameworks. The purpose of the integration is to provide end-to-end seamless scaling to such frameworks in a way that doesn't require changes to the application. A good example is our Mule-ESB support. Mule users can take existing Mule 2.0 applications and significantly improve performance and scalability by plugging in the GigaSpaces runtime into the Mule Framework. The good news is that the wiring happens outside of your application code at a couple of levels:

1. Connector level – leveraging our messaging layer as the transport for Mule
2. Clustering level – taking advantage of our clustering capabilities, enabling the internal Mule data structure to span across multiple machines for scalability and high-availability

This integration is provided as part of our open source framework, OpenSpaces. We hope and anticipate that these integrations will be used as a reference by other frameworks looking for ways to provide similar levels of scalability and reliability. A good example for that already happening is the work David Greco performed by integrating the Camel open source ESB with GigaSpaces.

With 6.6 we also added out-of-the-box integration to Jetty. This was done in collaboration with the Webtide team (the company behind Jetty), who have given us excellent support throughout the process. What i like about this integration is that it enables taking an EXISTING web application packaged as a WAR and dynamically scaling it across a pool of machines. With this approach, you also get session-replication injected to your existing application without touching your code or WAR package. If you're willing to make slight configuration changes, you can get caching reference injected into your application. There is a new example that shows what it takes to scale an existing web application. The example uses the Spring Pet Clinic application and deploys it on a GigaSpaces cluster. The full example is available here.

Removing the language barrier

For decades language have been treated almost as a religion by developers. As an ex-CORBA guy, I know how much language interoperability is painful to deal with, and often requires compromises on functionality, performance and complexity. At GigaSpaces, we realized that there is no reason that different languages shouldn't be treated simply as forms of writing business logic. They each generate different values. For example, .Net provides better integration with Windows applications. C++ provides better performance in certain areas and provides low level APIs for integration with many third-party libraries.

Persistence: 6.5 has some major enhancements for implementing our Persistence-as-a-Service model in .Net through support of nHibernate. This enables .Net applications to integrate with existing databases and have their own database mapping layer with a native .Net API. This comes along with quite extensive Perforamance improvements. You can see some of the results here for .Net, and here for C++.

One of our goals for 6.5 was to bring the same level of scalability and simplicity we provide for Java to .Net and to C++, without compromising performance. Unlike some of the alternatives in the market, we don't just provide remote access to our Java runtime, but provide complete application server capabilities in these two languages -- as well as complete interoperability among all three. Java, C++ and .Net services and clients can run and share the same process and leverage that to remove the network call overhead often required when a call crosses language boundaries. An immediate benefit is that you're able to run your C++ and .Net business logic where the data is. Furthermore, you can now leverage our existing SLA-driven deployment to automate the deployment of Java and .Net applications. This means that instead of running each server process manually, you have a single deployment command that will make sure that your serves are running on the appropriate machines, that your backups are running on different hosts from your primaries, that if one machine goes down a new instance will take over immediately, or if one is not available, as soon as it becomes available -- all that without any human intervention!

Dynamic language support

The Java framework guys realized the need to support dynamic language as part of Java, making the JVM a common platform for running various languages. GigaSpaces XAP 6.5 leverages this, and provides enhanced support for Groovy, JRuby and JavaScript.

Dynamic language support enables writing business logic in Groovy/Jruby/JavaScript and executing it on the GigaSpaces cluster. One of the common use cases for this capability is to provide an elegant alternative to Stored Procedure. this means you can write business logic in Groovy, for example, that will be executed directly on the data grid nodes. With this, you can write your own custom data-queries and aggregation functions, and execute them where the data is. Beyond the performance benefit that you gain out of running the logic collocated with the data, you gain the benefit of using dynamic languages, i.e., you can add new functions on the fly without the need to deal with class-versions and class-loading issues and without the need to bring the data down whenever you do that. In this way you can add new functions while the system is running and continues to serve other applications.
This feature leverages the SVF mentioned above. This means that you can choose to run these dynamic procedures synchronously, asynchronously, in parallel, etc. Now Isn't that cool?

Click here for code snippets and detailed descriptions of this feature.

Data awareness everywhere
Throughout all of our development efforts, we are making sure data-awareness is maintained across the entire stack. Data-awareness means that invoking a method on the new Service Virtualization Framework can be routed to a particular service instance based on the data associated with that service instance. It also means that when you send a message through our JMS implementation, you we will be able to route it to the JMS partition that manages the relevant data. Unlike alternative solutions, this is native to our environment, meaning that there is no need for external integration and complexity to achieve this behavior.

Click here to view a code snippet and detailed description of how routing is handled in the Service Virtualiztion Framework.

Performance, Performance and more Performance...
Improving performance remains a constant goal for all of our releases. As the product matures, finding places in the product where performance can be further optimized is getting harder, and I therefore am always surprised when one of the developers comes up with some creative idea around performance.

In this release we improved performance on several fronts -- including Java, .Net and C++ -- which involved significant optimizations of object serilization and multi-core scalability. For the latter we are working with Azul, and making it part of our testing environment, as well as other multi-core systems such as Sun Niagra. You can see some of the figures and details here, here (Comparison with previous release of .Net) and here(C++).

We conducted detailed comparisons of latency and throughput of a "classic" transactional application based on the standard JEE model (Using JBoss ,JMS, Spring, Hibernate) with the same application but using GigaSpaces as the messaging and data-layer -- and eventually replaced the entire JEE stack with a GigaSpaces + Spring stack. It is important to note that throughout this process, the business logic code remained untouched. The initial results of this tests can be found here:

You can find the details of the code that was used in this test and the migration steps in a new whitepaper that is now available on our site here.  Uri Cohen wrote up in his blog (The Space as a Messaging Backbone) some of the interesting findings from this analysis that showed the difference between end-to-end measurment and point optimization and why in some cases putting a distributed cache in front of a database is not going to be enough.

What's next:

For obvious reasons I can't expose our entire roadmap as of yet. What I can say for sure is that we're going to continue improving the level of seamless and simple scalabaility provided by our platform.

We view the partnership and integration with other frameworks as strategic, and we're going to continue with that effort. One of the frameworks we are planning on working on is GlassFish.

We already announced our first cloud offering, designed to run on Amazon EC2, and including partnerships and integration with RightScale and Cohesive FT. If I'm not mistaken, this was the first Java application server available in a pay-per-use model, designed to meet the needs of enterprises and ISVs that want to offer their applications on the cloud, including as Software-as-a-Service. We're going to put in a lof of effort into making cloud deployments simpler, enabling our customers to use it on their local virtualized environments (private clouds) and on public clouds (Amazon EC2, GoGrid, FlexiScale, AppNexus and others), or even a combination of the two, without changing their applications. We're now working on a new version that enables provisioning a cluster of machines, deploying the application on said cluster and opening up an adminstrative console for the cluster -- all with a single click. This is already working in an internal beta. We're planning to provide a preview release by next month. With the availability of Windows-based clouds, we will be providing our .Net application platform as a cloud offering as well.

On the API and Standards front, we recently joined the OSGI alliance, where we expect to play an active role.  We are also looking into ways through which we can strengthen our compliance with some of the latest standards on the JEE stack, such as EJB 3.0 and JPA. The challenge is not just basic API mapping, but how to do it in a way that doesn't break our scale-out architecture and doesn’t create complexity. Unfortunately, previous versions of the EJB spec weren't a good fit. EJB 3.0 looks much more promising.

On the .Net front, we're going to continue with our performance optimization project. We're also working on making our .Net offering fit natively within a .Net development environment by providing better development and installation packages that fit better with the .Net spirit. We are also looking into ways to simplify the testing and debugging process. For pure .Net users we will make the .Net version available as a standalone package at a reduced price (details will follow).

On the C++ front, we're going to provide our customers with an open source version of our C++ binding and a complete package that will enable them to compile and build our C++ with their own set of dependencies, libraries and compiler versions and flags. This will also allow using the current C++ framework as a broad integration framework for third-party tools and languages.

There's much more than I could cover in this post. I tried to put together what I thought are the highlights of the release. As it's impractical to cover such a wide spectrum of topics in a single post, we started a process in which different people from our R&D and field engineering teams will post on specific aspects of the product and best-practices for using GigaSpaces in existing web, financial, online gaming and other applications.

Be part of our next release:
As we are now making the decisions of what to include in our 7.0 release, it would be nice to hear your feedback and specific requests for enhancements or new features. You can either send me a direct email or send it to PM at GigaSpaces.com Alternatively, if you think that you have a good idea that other users might be interested in, you can implement it on our community site – OpenSpaces.org.

The new GigaSpaces XAP 6.5 is available for download here.

What a year!

For the past few days I've been trying to write a 2007 summary, but I found this task to be extremely difficult because so many things happened this year on so many fronts. I thought that it would probably be best if I'll start by thanking all of our customers who chose GigaSpaces. Special thanks to those who were kind enough to be public about their choice as you can see here ,here and here

This year we saw that many customers found that GigaSpaces and caching solutions are almost incomparable due to the tremendous progress we have made with our 6.0 release (More details provided below). This led to an interesting trend: Customers who already worked with one of the alternative caching products decided to add GigaSpaces to their environment in conjunction with those caching products. In this context GigaSpaces acts as a high-performance SOA platform through the use of our SLA-Driven Container, as well as the messaging bus and Spring components. In fact, in Q4 we closed a very large enterprise deal with one of the leading investment banks for exactly this reason.

I expect that during 2008 we'll see more of this as we plan to provide official support for these sorts of mixed environments. If you think about it, it makes prefect sense. In the JEE world this is a fairly common scenario. For example, it's common to have WebLogic as the application platform in conjunction with other components, such as databases or messaging middleware from other providers, even though WebLogic offers these components. I call that a middleware mash-up:)

Another interesting trend that we've seen is a new class of customers using GigaSpaces:

1. Customers from other industries, such as Web 2.0 and online gaming (as you can imagine, there is similarity between the two)
2. Customers who chose GigaSpaces mainly to improve the reliability and responsiveness of their online services. This included online banking applications as well as an order management system for the launch of a cool phone in Europe (I apologize that at this point I can't give more details).

We've also seen increasingly more customers who chose Spring+Hibernate as their middleware stack and wanted to maintain the high availability, scalability and performance of their Spring application without the complexity of J2EE.  Rod Johnson of SpringSource gives a nice explanation of this in this presentation, which is available online here (See slide 33), and in this blog post:

Is it a Tomcat, or the Elephant in the Room?

"...An interesting force is that the highest performing grid/clustering solutions are not the app servers themselves, but specialist solutions such as GigaSpaces, Oracle Coherence and IBM ObjectGrid. There is no reason that HA features need to be associated with Java EE servers."

From a product perspective, we had ambitious goals to enable the scaling-out of stateful applications (the entire application, not just the data) in a way that will be as simple as running it on single machine. The other challenge was to enable the transition of EXISTING tier-based applications to the scale-out model in a *seamless* manner, just by plugging-in our runtime implementation.

We managed to achieve these goals by working on several fronts:    

• Develop a blueprint based on best practices to achieve scaling, latency, performance and reliability in a scale-out model. We refer to this blueprint as Space Based Architecture (SBA).
• Extend our product to support SBA by adding built-in components, such as the processing-unit, and event containers.
• Provide an end to end approach for virtualization of the application in a scale-out model through:

• Middleware virtualization - (Data, Messaging, Services)    
• Deployment virtualization - through our SLA driven container

• Provide seamless transition from the tier-based model to a scale-out model through API facades and declarative abstractions. 

To validate our assumptions, we took a classic transactional application based on the tier-based model and compared it with SBA in terms of complexity, performance and latency . We applied the SAME CODE to both tests (the only change was within the DAO). The results of the test showed, beyond any reasonable doubt, that Space-Based Architecture can drive applications to linearly scalable performance and flat latency during scaling events. You can view the results of this test in the following presentation Scale Out Your Spring Applications in 3 Simple Steps. More details can be found here.

On the data virtualization front, we introduced capabilities such as PaaS - Persistency as a Service and .Net support that addresses both performance and the completeness of our Java-based feature set, including support for SBA (not just caching), and pure .Net components, such as SessionState. We already customers who have been in production for some time with a pure .Net system, built entirely on top of GigaSpaces.

Later in the year we introduced our partnership with Microsoft and our strategic integration effort with Excel. You can find more details on this exciting solution in this white paper. I also gave an online demonstration of it in the latest Grid Association event available online here.

We have also made significant progress with our C++ version, and have prospects running with our private beta of our new C++ support. The new C++ release is going to revolutionize the simplicity in which C++ applications can be written in a distributed environment.  Public beta will be available until end of January .

What's interesting is that we were able to maintain native API support in each language and complete interoperability among Java,.Net and C++ using what we refer to as Portable Binary Serialization format (PBS). This enables interoperability without compromising on performance! We are even able to run C++ services as part of our SLA driven container, which means that you can deploy C++ services just by pointing your service to the dll or shared library. This means that the C++ service can also run embedded within our OpenSpaces Processing Unit.

We made a huge effort in ensuring all these new capabilities are simple to use. Our choice of Spring for our new development framework - OpenSpaces - paid a lot of dividends, as it enabled us to simplify not just how you wire the caching component to your application, but also how you develop, test and scale your entire application in a "cloud" environment. To Spring users, OpenSpaces will fell like a native extension of their existing development framework, where complex things such as transaction handling, partitioning, scaling, fail-over and deployment are abstracted from their development code. Here's an example of feedback we received from one new user who tried our platform, Srini Penchikala:

I have been trying GigaSpaces on my local computer to learn more about
the framework. It's a great implementation that supports simple design and
a scalable and performant solution. Integration with Spring framework makes
GigaSpaces even more powerful.

You and your team have created a great product.

Another effort that helped us achieve simplicity is our award-wining documentation wiki and its Quick Start Guide and webcasts, which provide a walkthrough for writing your first scalable application.

In 2007 we also launched several major community and open source initiatives. One such initiative was our open source development framework, OpenSpaces. Another one was the Start-Up Program (which complements our existing free community edition).  We also announced our killer application contest, in which users can put their skills in distributed programing and scaling to the test and win a $10k grand prize. Some of the interesting submissions that have already been made include applications that will scale on Amazon EC2, scaling the Lucene search engine, scaling gaming applications, integrating OpenSpaces with PHP and other cool ideas. We're going to continue down this path during 2008, and open up more aspects of GigaSpaces, such as our Product Management processes. See below what one of our users had to say on our forum:

All I want to say is that the forum is awesome....so quick response. Thank you all involved with GigaSpaces for providing such nice support

We will also be officially announcing our new developer community portal, OpenSpaces.Org, by the end of January. It is a collaboration platform for users in the GigaSpaces community by sharing code, suggesting and contributing extensions, as well as providing tools and examples.

Now if this wasn't enough innovation wait until you see what we have planned for cloud computing:) We started an effort to enable GigaSpaces deployment on the Amazon Elastic Compute Cloud (EC2). We're about to release our second update of this and the plan is to have it fully integrated with our product release in 2008.

When I look back I'm quite proud of how a company our size is able to get all of this done. Indeed, we wouldn't have been able to achieve all of this if it weren't for the tremendous effort of our R&D team. It started with some new strategic hires and continued with a major investment in making our development process extremely efficient by applying new agile development methodologies such as Scrum (see this from Guy Nirpaz, EVP of R&D, here).

We also made a substantial investment in automating our testing process by developing a distributed testing framework we call Tigris. This framework enables us to run tests on multiple platforms (Windows, Linux, Solaris), Java (1.4, 1.5, 1.6, Sun, JRockit, IBM), .Net, c++ (Windows 32/64, Linux 32/64) with different cluster sizes and topologies -- all fully automated. It has become so successful that we're actually being pressured by our customers to provide them with our testing framework and consult them on our methodologies.

2008 looks very promising. I see great opportunity for GigaSpaces to become the de-facto scale-out platform. I expect to see continued adoption from the in the Spring community seeking a solution for scalability and high-availability, without the complexity of J2EE. I also expect to see greater adoption in the Web 2.0 market, as we're adding support for dynamic languages, as well as integration with web frameworks. As I mentioned, we're going to continue our effort to support Amazon EC2 as part of our platform to enable a simple evaluation of our product, run distributed testing and run a full-blown on-demand production environment. I expect that the significant progress on the .Net and C++ fronts with our next release will enable us to further penetrate those areas as well.

I'm very excited by all this progress and working closely with customers who are building their mission critical applications on top of GigaSpaces. What's nice about it is that our customers never cease to amaze me with their appetite for achieving even more. They are moving so fast in building large clusters that one of our next goals is to allow simple, out-of-the-box large cluster deployment and massive object sizes. With all this excitement,  I decided that this year I am finally going to spend some time and write a book...

Happy New Year!

Lessons from Pat Helland: Life Beyond Distributed Transactions

Distributed Transactions are a common pattern used to ensure ACID properties are met between distributed resources. Since the late 70s, the fIrst generation of this model has been widely used in many large-scale applications that struggle with the difficulties of multiplexing many online terminals. This led to the emergence of the 1st generation TP Monitors (TPMs), such as Tuxedo (Now owned by BEA). The emergence of web based applications in the late 90s drove the creation of 2nd generation TPMs, in the form of JEE application servers, to address similar needs using more open and modern technologies as described in the following article by Subbu Allamaraju: Nuts and Bolts of Transaction Processing. The diagram below illustrates a typical transaction flow in a JEE environment:

       

Transactions in EJB Application Server
(Source: Subbu Allamaraju, Nuts and Bolts of Transaction Processing)

The increased business demand for greater scalability led many to the realization that the current transaction model is a bottleneck due to its inherit centralized approach. It also makes our systems quite brittle and complex due to the tight coupling that it introduces, as described in a paper by Pat Helland of Amazon.com: Life beyond Distributed Transactions: an Apostate’s Opinion:

Today, we see new design pressures foisted onto programmers that simply want to solve business problems. Their realities are taking them into a world of almost-infinite scaling and forcing them into design problems largely unrelated to the real business at hand. Unfortunately, programmers striving to solve business goals like eCommerce, supply-chain-management, financial, and health-care applications increasingly need to think about scaling without distributed transactions. They do this because attempts to use distributed transactions are too fragile and perform poorly.

This challenge leads us to the emergence of a third generation of TPMs,  or what Gartner calls Extreme Transaction Processing (XTP).

What approaches are people taking today to overcome the limitations of previous generations? From Pat:

"..Because the performance costs and fragility make distributed transaction impractical. Natural selection kicks in,... applications are built using different techniques which do not provide the same transactional guarantees but still meet the needs of their businesses"

So the question is how to achieve high transactional throughput and performance without compromising consistency and reliability?

Pat Helland suggest the following principles:

• Instead of global transactional serializability we assume multiple disjoint scopes of transactional serializability
• Scalable Apps Use Uniquely Identified “Entities” [Nati: Entities represent data elements that are equivalent to Tuples in Space-Based Architecture terminology]
• Atomic Transactions Cannot Span Entities
• From the programmer’s perspective, the uniquely identified entity is the scope of serializability
• Messages Are Addressed to Entities [Nati: in other words, we use messages to manage the workflow between the disjointed transactions - this is pretty much the equivalent of a transaction coordinator].
• Entities Manage Per-Partner State (“Activities”) [Nati: in GigaSpaces terminology: each activity is executed within a collocated partition].

In order to avoid distributed transactions you must:

• Create/rearrange your object model using entities (objects with IDs), in a such a way that most of your state changes will happen inside the boundaries of a single entity. a change to a single entity is atomic.
• For those changes that exceed the boundaries of one entity, changes will not be atomic and the final desired change will be achieved using a sequence of atomic changes, every change request (activity) MUST be implemented to be idempotent because of the chance of retransmitting due to failures.
• To accomplish idem-potency of your activities (actions/methods) the entity itself SHOULD hold a history of committed activities per source(entity).

Combining these three principles allows you to safely change the state of the application without distributed transactions, while allowing for almost infinite scaling.

How does this apply to SOA? 

A core principle in SOA, event-driven architecture (EDA) and grid computing is the notion of loose coupling of services. The distributed transaction model leads to tight coupling by definition, as it requires intimate integration and runtime dependencies among all of the services that are associated with a transaction. The suggested model of "disjoint transactions" fits in nicely with this type of new architecture. Here's Pat again:

Everything discussed in this paper is supportive of SOA. Most SOA implementations embrace independent transaction scopes across services. The major enhancement to SOA presented here is the notion that each service may confront almost-infinite scaling within itself and some observations about what that means. These observations apply across services in a SOA and within those individual services where they are designed to independently scale.

Pat ends with:

In a few years we are likely to see the development of new middleware or platforms which provide automated management of these applications and eliminate the scaling challenges for applications developed within a stylized programming paradigm. This is strongly parallel to the emergence of TP-monitors in the 1970s.

Guess what, Pat, the future is now!

In a the next post i'll discuss how Space Based Architecture (SBA) and GigaSpaces XAP as the implementation of SBA follow similar principles to those described by Pat Helland in a very elegant way that fits perfectly with SOA, EDA and Grid.

Additional References:

• Shay Banon on Scalability Mythbusters
• InfoQ discussion on New patterns and middleware architecture needed for true linear scalability?

 

High-Performance SOA

More and more people are realizing that Web Services are not the only way to implement SOA based application. A recent InfoQ discussion thread,  SOA != WebServices, raised this discussion again:

Jason [Bloomberg] thinks it is now the time to better separate the concepts and let SOA evolve in higher levels of abstraction

Geva Perry covered the topic of  Scalable SOA in one of his recent blogs.
Geva quotes Dave Linthicum ("SOA for the real world"):

Making solutions scale is nothing new. However, the SOA technology and approaches recently employed are largely untested with higher application and information and service management traffic loads. SOA implementers were happy to get their solutions up-and-running, however in many cases scalability is simply not a consideration within the SOA, nor was load testing, or other performance fundamentals. We are seeing the results of this neglect now that SOA problem domains are exceeding the capacity of their architectures and the technology in many instances.

While I think that many technical folks are in violent agreement that Web Services and SOA are not necessarily the same thing, the question: what is the alternative approach? remains unanswered

 Quoting Jason Bloomberg from his Principles of SOA article:

The most important missing piece, however, is the top-down approach to SOA outlined in this article. Most of today's thinking about Web services is bottom up: ''Here's how to build Web services, now let's use them for integration."

Everyone seems to be struggling to define an alternative approach to WS*, however, very few provide a clear end-to-end definition on how to turn existing stateful tier-based applications into linearly scalable services. Throwing a messaging-bus at the problem ain't gonna cut it. I would even argue that it could possibly make things worse.

There is a growing class of applications -- specifically those that are categorized as XTP (Xtreme Transaction Processing) applications -- in which SOA in its WS* form adds no value due to the fact that the services in this environment are stateful and need to interact at high speeds, while keeping the latency low.

So what should be the platform for High Performance SOA?

There are several emerging frameworks, such as OSGI and Mule, that provide an alternative SOA approach. What is common to these frameworks is the fact that they are POJO-driven, lightweight and highly efficient in terms of performance and footprint. It is therefore not surprising that these frameworks are gaining momentum and are becoming de-facto standards for building high-performance SOA applications.  While this initial set of platforms already exists, I think that we still lack the top-down view that Jason was referring to. That is where Space-Based Architecture fits in. In the following reference SBA and SOA I tried to describe how SBA fits into the SOA world as a pattern for turning stateful-tier-based-applications into linearly scalable services.

In his presentation, Scalable SOA, GigaSpaces VP R&D Guy Nirpaz covers at depth how you can use Space Based Architecture combined with Spring and potentially OSGi to bridge this gap and turn your existing tier-based stateful applications into linearly scalable services.