Click here to close now.

Welcome!

Java Authors: Pat Romanski, Elizabeth White, Liz McMillan, Esmeralda Swartz, Asad Ali

Related Topics: Java

Java: Article

Scalability of J2EE Applications: Effective Caching's Key

Scalability of J2EE Applications: Effective Caching's Key

Sooner or later all architects and developers of large-scale J2EE products face the same problem: their software's response time gets slower and slower, and the scalability of their solution is ending. This article investigates caching solutions that promise to help; sheds some light on their limitations; and describes an easy, lightweight, and effective caching mechanism that solves most of the issues.

Note: This article does not assess all possible ways of caching nor does it take solutions such as commercial external caching products into account.

The Problem
Whenever we build distributed software for a large scale - whether it's J2EE or not - we face the same challenge: keep response or transaction times low while increasing user load. The main problem is that essentially all software systems scale exponentially at some point (see Figure 1). Architecting and implementing a solution that keeps scalability linear and leaves enough room for increasing load as the business grows is a difficult task that requires experience.

A good architect keeps traffic, transaction times and volume, persistence layer design, and caching in mind when he or she drafts the first layout of a new architecture. Understanding concurrent access by n users on m data items is one of the major things an architect looks for.

Possible Solutions
Minimizing traffic in all tiers is the primary objective when creating a scalable solution. Figure 2 shows a typical three-tier system.

While the persistence tier in modern databases already provides significant caching capabilities, it's rarely enough for large-scale systems. What do other mechanisms do to increase performance and scalability, and to what tier/layer do they apply?

Stored Procedures?
I mention this because aside from caching, one suggestion I always hear is using stored procedures. I'd like to encourage everyone to consider different options. Using stored procedures splits the persistence layer over two physical tiers and usually improves only single user performance.

If you look at your application server's console, you might see, for example, that of the 500ms a servlet or JSP request takes, only 100ms are spent on the DB transaction side. Squeezing another 30ms out by using stored procedures rarely makes your system scale - you still need DB connections, cursors, and other resources.

Persistence Layer Caching
The easiest way to cache in J2EE systems is with entity beans (if we say entity beans let's only talk about CMP for the moment); I can hear the readers moan, but the fact remains: they are the only "good" way of caching in J2EE solutions. Why? Because the maximum cache size is controllable by setting the maximum number of beans and because the resource is in control of the container, as they can be passivated if memory is short. Usually, they are the only resource that is clusterable as well.

Why would most developers and architects say entity beans are bad for your performance? Because they are. In a single request use case, they have significant overhead compared to direct JDBC. But even in scalability assessments, entity beans often come out last, because their usage as a cache is determined by the possible cache hit rate, just like any other cache. The cache hit rate is determined by the number of reads versus the number of data items versus the number of writes.

Ultimately, if you use entity beans you really need to know what you're doing. While that might be true for any out-of-the-box mechanisms a container provides, it's especially true for entity beans. It's easy to get it wrong and a lot of containers have less than mediocre support for entity beans.

Entity beans make sense if:

  • Your reads and writes are few, then scalability is not your concern anyway and CMP EJBs are just as convenient.
  • Your reads are many, your writes and number of data items are few - this means maximum cache hit rate - you have just a few items to cache (most containers only perform well with a few thousand entity bean instances per CPU), and it rarely becomes stale because you hardly write.
In all other cases, entity beans just make things worse due to their management overhead. Figure 3 shows that cache efficiencies (like entity beans) depend on the number of reads versus the number of writes versus the number of rows (which is an oversimplified perception and not real math). Caching with entity beans works well within the green area.

One important fact needs to be considered as well: some application servers (WLS 6, WebSphere) do not support EntityBean clustering/ caching in clustered infrastructures. In other words, they often support only the caching of read-only entity beans if you run a cluster, which rules straight CMP out completely to increase scalability.

Let's have a quick look at BMP (mainly read-only or read-mostly BMP). These type of entity beans can be used to solve the problem of too many entity bean instances by allowing you to change the caching granularity: while CMP caches on a per-data-row basis, RO BMPs can essentially cache on any desired granularity level and are basically similar to the caching mechanism I'll discuss later. However, they still have a few disadvantages, such as the entity bean management overhead or (depending on your container implementation) the fact that they usually are - like all entity beans - single threaded: only one request at a time can access the cache.

In all other cases (mixed reads/ writes, lots of data, few reads many writes, etc.), how do we make our software scalable?

Web Tier Caching Using HTTP Session
If persistence layer caching through entity beans is ruled out, we have two tiers left where we could cache.

The most obvious choice developers often make is HTTP session caching. Since it caches at the uppermost tier, it should be most effective at minimizing traffic, right? However, using the HTTP session as a cache makes architects of large-scale systems shudder.

First, it caches on a per-session basis: it helps if one user performs the same or similar action 5,000 times but not if 5,000 users perform one action.

Second, the cache invalidation and GC is based on the session time-out - usually something like 60 minutes. Even if a user works for 10 minutes in your system, the data is cached for 60 minutes, which makes the cache size six times as big as it needs to be, unless you invalidate your session manually.

Finally, it removes one important task from the container: resource management. Since this cache cannot be cleared by the container, it often causes problems since the container cannot GC these objects even if memory resources become short. The container's GC cycles become more frequent and the GC has to walk over a large set of mainly stale objects in your session, making the cycles longer than they need to be.

Singletons and Application Context
The last place to cache is in the business layer (the following mechanism could be used in the Web tier as well). Since the HTTP session is not very effective at caching in high-traffic systems, the next best choice is using singletons to cache objects or data from the database.

Singletons (just like the application context) have the advantage that they again cache for all requests, but still are not a container-managed resource. Frequently singleton caches are implemented as a plain Hashtable and are unlimited in size, which causes almost the same problems as HTTP session caching.

I'd like to recall a simple but effective caching strategy that is singleton-based and uses a container such as a mechanism of resource management to keep resource usage to a minimum.

LRU Caching
The strategy used is called LRU (least recently used), also known as MRU (most recently used). Essentially, it only caches objects that are used frequently by limiting the cache size to a fixed number of items (hence the name), just like a container pool size for EJBs, thus keeping resource utilization controlled.

How does this work? Essentially it's a stack: if an object is requested from the stack and it's not there (cache miss), it's inserted at the very top. If your cache size is 1,000 items and the cache is full, the last item will fall off the stack and effectively be removed from the cache (see Figure 4).

In case an object is on the cache, it will be removed and reinserted at the top (see Figure 5).

This way, the most often used items will remain at the top, and the least used items will eventually drop off the stack. You can even keep track of your hits and misses easily and either query this information to reconfigure your cache or grow and shrink the maximum size dynamically. This way, you minimize usage of resources and maximize cache effectiveness. The stack implementation depends on your needs: choose an unsynchronized model if necessary to allow concurrent reads and minimize overhead.

Cache Invalidation
This cache works best in read-only or read-mostly scenarios. Unless you implement write-back or other write cache synchronization schemes or don't care that the cache is out of sync with the data source, you'll have to invalidate the cache, which decreases the cache hit rate and efficiency. For example, you can implement write-through caches fairly easily using dynamic proxy classes (JDK 1.3 introduced support for dynamic proxies) but that is a topic for another article.

Singleton-based LRU caching still has the typical problem of all singleton-based caches: a singleton is not a singleton in distributed systems (J2EE for that matter) but unique per classloader or server context (if you're lucky), and it's not kept in sync in clustered environments. There are, of course, mechanisms to implement the synchronization of distributed resources; some of them are difficult to implement or have scalability or availability issues; some work just fine. Distributed caching is not easy and if your requirements force you to go down this path, you might be well served choosing a commercial caching product.

The fact that you have several unsynchronized cache copies in clustered environments can be a big problem. The easy solution is using timed caches (just like read-only entity beans), which means that if a cached object is a certain age, it's considered stale and will be dropped from the cache. This is sufficient in most cases, but let's look at the following scenario.

Let's assume our invalidation time is 30 minutes (an object older than 30 minutes is considered stale). Cache A caches an object at 11:15, Cache B at 11:35. If the data item the cache is referring to is refreshed in the database at 11:40, Cache A will have the correct value at 11:45 when it expires but Cache B won't have it until 12:05 (see Figure 6). The problem now is that for 20 minutes you get different results - depending on which server you hit and on the use case this can be a big problem.

The solution for these cases is a timed cache that is refreshed at fixed points in time every n minutes, like at 12:00, 12:30, 1:00, etc. The advantage is that now all your caches are somewhat in sync (as in sync as the clocks on your servers are). The disadvantage is that the load on your servers increases quite a bit every time the caches are cleared, because they're cleared completely.

Which way you go depends on your business requirements; adjusting your refresh cycles largely depends on your data update frequency versus the cache hit rate you would like to achieve.

Of course, there are a variety of other ways to keep distributed copies of caches in sync, but these are not easy to implement and have a variety of side effects to consider.

Open Source and Commercial Caching Implementations
If your caching needs are more complex, or if you just don't want to "roll your own," you might want to give JSR 107 a look. This is the JCache JSR that specifies a distributed, resource-managed, Java-based cache. Even though little progress has been made to provide a production-ready implementation, there are several open source projects and products that are close to a JCache implementation and might provide what you need.

Commercial caching products should be considered if your caching requirements are complex (clustered environments, etc.). As mentioned earlier, distributed caching is not as easy at it seems and relying on an enterprise-class product often saves time and trouble.

Building a scalable solution often depends on making the right decisions in persistence mechanism and in caching. How, when, and where to cache is the trick; I hope this article helped you make the right decision.

References

  • JSR 104: www.jcp.org/en/jsr/detail?id=107
  • JCS and JCache at Apache: http://jakarta.apache.org/turbine/jcs/JCSandJCACHE.html
  • More Stories By Stefan Piesche

    Stefan Piesche is a Principal Architect for the Cobalt Group (HQ in Seattle) responsible for large-scale, distributed systems based on J2EE. In the past years I worked on several large-scale systems in Europe in the financial and airline industry.

    Comments (15) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Cameron 05/19/04 03:22:24 PM EDT

    Hi Jamal, cluster-wide means than any cluster node can request a lock, optionally queue for it (if it''s taken), and thus have the ability to safely work with data in-memory in the cluster, just like having "synchronized" as a keyword allows you to write thread-safe Java code. So just as "synchronized" is a necessary ingredient of scaling to multiple threads, the ability to manage locks and coherent data in a cluster is a necessary ingredient of horizontal scaling in a cluster.

    Jamal 05/05/04 04:53:20 PM EDT

    Perhaps I am misinterpreting the meaning of the ?cluster-wide? lock. It would seem that if you were locking a cache at the record level for a read/write operation, as the case may be, that the overall performance would degrade as the number of nodes increases because each node would effectively be locked until another node finished it?s work. This in turn creates a virtual cluster wide transaction (- ick -). A transaction of this nature can only decrease in performance as more nodes are added to the cluster.

    Cluster wide locks sound like a really, really bad idea for large-scale systems where scalability is key.

    Rob Misek 05/04/04 09:48:58 AM EDT

    Hi Jamal,

    The in-cluster operations generally start off more performant because they occur in-memory (and in Java) in the cluster in which the application is running, and do not have to go through inefficiencies of translating through the JDBC API. The icing on the cake is that the cluster performance does not degrade as more and more machines enter the cluster while the database performace decreases in the same situation. The operation stays at a relatively constant speed, regardless of of whether you have 2 servers or 20 servers in the cluster. Yet, with 20 servers you can manage 10x the throughput (as 2 servers).

    Jamal 05/03/04 09:19:11 PM EDT

    Rob, you indicate that Coherence provides cluster-wide locking as the concurrency mechanism. Can you please explain how a cluster-wide lock ?increases? performance?

    Rob Misek 04/28/04 04:30:37 PM EDT

    "For the data that are modified frequently and concurrently, they are best not to be cached."

    Actually, that is the area where you will see the largest performance improvement by caching. Coherence is used in this exact scenario since it provides cluster-wide locking as the concurrency mechanism.

    That coupled with the use of our "read-through/write-behind" technology when using an underlying datastore increases performance further. The huge advantage of a read-through/write-behind cache in a cluster is that the database is almost completely unloaded of repetitive read operations, and more importantly the database is unloaded from repetitive writes, which are usually much more expensive than read operations. Combined with the HA features of Coherence, even the write-behind data is managed safely during failover, allowing an application server to unexpectedly fail without any loss of uncommitted (write-behind) data.

    Stanley 04/28/04 12:41:54 AM EDT

    The more important thing is to determine what to cache and how much to cache. All applications use some kind of reference data that are used application-wide and change very infrequently. These can be cached at global level, at web/business tier using either singleton or application context. They can be refreshed overnightly and/or on demand. We have successfully implemented this type of cache in a number of projects, with custom notification mechanism to synchronize the caches on clustered servers.

    The Session object has also a place to cache certain types of data, such as those that are applicable mainly to the user session, hardly shared with other users, infrequently modified (rarely modified by other users while the user session is active). However we shall not store too many objects in the Session or the application will not scale.

    For the data that are modified frequently and concurrently, they are best not to be cached.

    I agree with Stefan that Entity EJB is not a good place to implement caches.

    Jim Carroll 04/21/04 12:00:15 PM EDT

    Your article is interesting but if scalability is your main aim (as the first paragraphs imply) then a thorough discussion of how to design out server maintained state information can be more important than sophisticated caching. Rather than recommending the use of Entity beans, designing a system that eliminates (or minimizes) their need (since they are, by definition, server managed state) will go much further toward a truly "linearly scalable" distributed system.

    Regards,
    Jim

    Cameron 04/15/04 02:13:39 PM EDT

    Hi John, those limitations do not apply to system libraries, such as JDBC drivers, which *must* open sockets in order to communicate with a database running in a different process or on a different machine.

    The rules for EJBs, particularly the limitations, are there to restrict the component developer (someone writing an EJB that may be deployed to any application server) so that they are assured of the highest level of portability. The spec now explains a lot of the limitations. For example, if you access the file system, and the application server is clustered, how can you be sure that the file will be there when you fail over (since it might be a local file system, or the machine that is failed over to could be running on a completely different site!)

    Similarly, managing threads and sockets may be disabled for the EJB components from a security perspective, to allow for controlled environments for third party hosting of applications.

    IBM is working to standardize APIs so that the container can expose things like thread pooling to the component developer. In the mean time, those things should be considered off limits to an EJB developer if you want to make your EJBs as portable as possible. However, system libraries are still able to (and often must) use those APIs to implement features like database connectivity.

    Peace.

    John Segrave 04/15/04 01:21:27 PM EDT

    It strikes me that there''s little difference between an EJB Bean class calling a prohibited API and the Bean class calling an intermediate class which calls the prohibited API.

    Does EJB make a provision for when there is no alternative but to call these APIs? e.g. You can call them, as long as the call is routed through an XXX? (eg resource adapter? don''t really know much about resource adapters, apologies if this is a meaningless suggestion). How is a JDBC driver supposed to access a remote DB without making socket calls?

    Cheers,

    J

    Cameron 04/13/04 11:38:22 AM EDT

    A system library, such as Coherence or a JDBC driver or a JMS implementation, is allowed to manage socket communication, while an EJB component is not. Optionally, you can use Coherence as a transactional resource through the J2CA (Java 2 Enterprise Edition Connector Architecture) API.

    As far as compatibility, Coherence has hundreds of production deployments on numerous application server platforms (including WebSphere 3.5.4 - 5.1 and WebLogic 4.5.1 - 8.1) on JDK 1.2 - 1.4.

    Peace.

    John Segrave 04/13/04 02:53:36 AM EDT

    Hi Cameron, thanks for the replies.

    To my reading, the EJB 2.0 spec (section 24.1.2 to be precise!) appears to prohibit the use of multicast sockets: "An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast."

    I''m genuinely not trying to be argumentative here, just trying to work out whether or not Coherence does or doesn''t contravene the spec, and if it does, was it done intentionally (in which case, what was the reason)?

    Normally, I''d expect an intentional contravention of a spec to be accompanied by an explanation (so customers can make up their own minds whether or not they think it may cause them problems). I''d like to give Coherence (and several other caching products) the benefit of the doubt, but at present that would be based on faith rather than evidence!

    Cameron 04/08/04 10:12:04 AM EDT

    Tangosol Coherence is built on top of a peer-to-peer cluster and uses the TCMP protocol, which is an asynchronous, dynamically-switched unicast/multicast datagram protocol, with reliable in-order delivery of cluster messages. Unlike simple invalidation strategies, Coherence maintains a coherent image of the data across the cluster, and supports fully replicated caches, cluster-partitioned caches, near caches, overflow (to NIO buffers and/or disk) caches, and database-backed caches.

    John Segrave 04/08/04 08:31:32 AM EDT

    What does it use for propagating cache messages in clusters - JMS, sockets? If sockets, does it do blocking reads?

    Cameron 04/07/04 04:47:18 PM EDT

    Tangosol Coherence is supported on basically all Java / J2EE application servers, and doesn''t screw with anything like setMessageListener(). It''s also the most mature and widely deployed clustered caching solution in the market.

    John Segrave 04/07/04 08:36:04 AM EDT

    I recently investigated several open source and commercial caching products and hit somewhat of a brick wall with the J2EE & EJB specs.

    I needed a cache to serve read-mostly data in a clustered EJB application. The application runs on several app servers, so portability was a key requirement.

    In my experience, the key element in ensuring portability is standards compliance. The J2EE and EJB specs forbid EJBs from using certain APIs, namely those that create threads, block on socket operations, etc. They go even further by explicitly naming forbidden APIs, such as JMS''s setMessageListener().

    However, pretty much all the caching products I investigated were using these APIs.

    In one example, I queried the vendor (who shall remain nameless!) about the use of setMessageListener() in their product. They replied by stating that (a) it works and (b) it was fine to use those APIs in classes that the EJB *uses*, just not in the *actual* EJB bean class itself.

    My feeling on (a) was that, if it contravenes the spec, then working on AppServer version X doesn''t guarantee it will work on version X+1. It also doesn''t mean it will work on any other app server. On (b) I don''t see that it makes any difference whether the call is in class A or in class B which gets called from A (in the same thread)?!... The vendor in question had only recently started marketing their product as a J2EE cache (previously it had been best known as a servlet cache). I don''t know if those restrictions apply to the web tier.

    In the end, due to portability concerns, we decided to roll our own. Our invalidation strategy was simple and was achievable using JMS and MDB''s (no spec contravention required).

    I''d be interested in other people''s experiences and perspectives on this topic.

    @ThingsExpo Stories
    The WebRTC Summit 2014 New York, to be held June 9-11, 2015, at the Javits Center in New York, NY, announces that its Call for Papers is open. Topics include all aspects of improving IT delivery by eliminating waste through automated business models leveraging cloud technologies. WebRTC Summit is co-located with 16th International Cloud Expo, @ThingsExpo, Big Data Expo, and DevOps Summit.
    Temasys has announced senior management additions to its team. Joining are David Holloway as Vice President of Commercial and Nadine Yap as Vice President of Product. Over the past 12 months Temasys has doubled in size as it adds new customers and expands the development of its Skylink platform. Skylink leads the charge to move WebRTC, traditionally seen as a desktop, browser based technology, to become a ubiquitous web communications technology on web and mobile, as well as Internet of Things compatible devices.
    SYS-CON Events announced today that robomq.io will exhibit at SYS-CON's @ThingsExpo, which will take place on June 9-11, 2015, at the Javits Center in New York City, NY. robomq.io is an interoperable and composable platform that connects any device to any application. It helps systems integrators and the solution providers build new and innovative products and service for industries requiring monitoring or intelligence from devices and sensors.
    Docker is an excellent platform for organizations interested in running microservices. It offers portability and consistency between development and production environments, quick provisioning times, and a simple way to isolate services. In his session at DevOps Summit at 16th Cloud Expo, Shannon Williams, co-founder of Rancher Labs, will walk through these and other benefits of using Docker to run microservices, and provide an overview of RancherOS, a minimalist distribution of Linux designed expressly to run Docker. He will also discuss Rancher, an orchestration and service discovery platf...
    Wearable technology was dominant at this year’s International Consumer Electronics Show (CES) , and MWC was no exception to this trend. New versions of favorites, such as the Samsung Gear (three new products were released: the Gear 2, the Gear 2 Neo and the Gear Fit), shared the limelight with new wearables like Pebble Time Steel (the new premium version of the company’s previously released smartwatch) and the LG Watch Urbane. The most dramatic difference at MWC was an emphasis on presenting wearables as fashion accessories and moving away from the original clunky technology associated with t...
    SYS-CON Events announced today that Vitria Technology, Inc. will exhibit at SYS-CON’s @ThingsExpo, which will take place on June 9-11, 2015, at the Javits Center in New York City, NY. Vitria will showcase the company’s new IoT Analytics Platform through live demonstrations at booth #330. Vitria’s IoT Analytics Platform, fully integrated and powered by an operational intelligence engine, enables customers to rapidly build and operationalize advanced analytics to deliver timely business outcomes for use cases across the industrial, enterprise, and consumer segments.
    SYS-CON Events announced today that Solgenia will exhibit at SYS-CON's 16th International Cloud Expo®, which will take place on June 9-11, 2015, at the Javits Center in New York City, NY, and the 17th International Cloud Expo®, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. Solgenia is the global market leader in Cloud Collaboration and Cloud Infrastructure software solutions. Designed to “Bridge the Gap” between Personal and Professional Social, Mobile and Cloud user experiences, our solutions help large and medium-sized organizations dr...
    SYS-CON Events announced today that Liaison Technologies, a leading provider of data management and integration cloud services and solutions, has been named "Silver Sponsor" of SYS-CON's 16th International Cloud Expo®, which will take place on June 9-11, 2015, at the Javits Center in New York, NY. Liaison Technologies is a recognized market leader in providing cloud-enabled data integration and data management solutions to break down complex information barriers, enabling enterprises to make smarter decisions, faster.
    @ThingsExpo has been named the Top 5 Most Influential M2M Brand by Onalytica in the ‘Machine to Machine: Top 100 Influencers and Brands.' Onalytica analyzed the online debate on M2M by looking at over 85,000 tweets to provide the most influential individuals and brands that drive the discussion. According to Onalytica the "analysis showed a very engaged community with a lot of interactive tweets. The M2M discussion seems to be more fragmented and driven by some of the major brands present in the M2M space. This really allows some room for influential individuals to create more high value inter...
    After making a doctor’s appointment via your mobile device, you receive a calendar invite. The day of your appointment, you get a reminder with the doctor’s location and contact information. As you enter the doctor’s exam room, the medical team is equipped with the latest tablet containing your medical history – he or she makes real time updates to your medical file. At the end of your visit, you receive an electronic prescription to your preferred pharmacy and can schedule your next appointment.
    The world's leading Cloud event, Cloud Expo has launched Microservices Journal on the SYS-CON.com portal, featuring over 19,000 original articles, news stories, features, and blog entries. DevOps Journal is focused on this critical enterprise IT topic in the world of cloud computing. Microservices Journal offers top articles, news stories, and blog posts from the world's well-known experts and guarantees better exposure for its authors than any other publication. Follow new article posts on Twitter at @MicroservicesE
    The list of ‘new paradigm’ technologies that now surrounds us appears to be at an all time high. From cloud computing and Big Data analytics to Bring Your Own Device (BYOD) and the Internet of Things (IoT), today we have to deal with what the industry likes to call ‘paradigm shifts’ at every level of IT. This is disruption; of course, we understand that – change is almost always disruptive.
    SYS-CON Events announced today the IoT Bootcamp – Jumpstart Your IoT Strategy, being held June 9–10, 2015, in conjunction with 16th Cloud Expo and Internet of @ThingsExpo at the Javits Center in New York City. This is your chance to jumpstart your IoT strategy. Combined with real-world scenarios and use cases, the IoT Bootcamp is not just based on presentations but includes hands-on demos and walkthroughs. We will introduce you to a variety of Do-It-Yourself IoT platforms including Arduino, Raspberry Pi, BeagleBone, Spark and Intel Edison. You will also get an overview of cloud technologies s...
    SYS-CON Events announced today that SafeLogic has been named “Bag Sponsor” of SYS-CON's 16th International Cloud Expo® New York, which will take place June 9-11, 2015, at the Javits Center in New York City, NY. SafeLogic provides security products for applications in mobile and server/appliance environments. SafeLogic’s flagship product CryptoComply is a FIPS 140-2 validated cryptographic engine designed to secure data on servers, workstations, appliances, mobile devices, and in the Cloud.
    SOA Software has changed its name to Akana. With roots in Web Services and SOA Governance, Akana has established itself as a leader in API Management and is expanding into cloud integration as an alternative to the traditional heavyweight enterprise service bus (ESB). The company recently announced that it achieved more than 90% year-over-year growth. As Akana, the company now addresses the evolution and diversification of SOA, unifying security, management, and DevOps across SOA, APIs, microservices, and more.
    GENBAND has announced that SageNet is leveraging the Nuvia platform to deliver Unified Communications as a Service (UCaaS) to its large base of retail and enterprise customers. Nuvia’s cloud-based solution provides SageNet’s customers with a full suite of business communications and collaboration tools. Two large national SageNet retail customers have recently signed up to deploy the Nuvia platform and the company will continue to sell the service to new and existing customers. Nuvia’s capabilities include HD voice, video, multimedia messaging, mobility, conferencing, Web collaboration, deskt...
    SYS-CON Media announced today that @WebRTCSummit Blog, the largest WebRTC resource in the world, has been launched. @WebRTCSummit Blog offers top articles, news stories, and blog posts from the world's well-known experts and guarantees better exposure for its authors than any other publication. @WebRTCSummit Blog can be bookmarked ▸ Here @WebRTCSummit conference site can be bookmarked ▸ Here
    SYS-CON Events announced today that Cisco, the worldwide leader in IT that transforms how people connect, communicate and collaborate, has been named “Gold Sponsor” of SYS-CON's 16th International Cloud Expo®, which will take place on June 9-11, 2015, at the Javits Center in New York City, NY. Cisco makes amazing things happen by connecting the unconnected. Cisco has shaped the future of the Internet by becoming the worldwide leader in transforming how people connect, communicate and collaborate. Cisco and our partners are building the platform for the Internet of Everything by connecting the...
    SYS-CON Events announced today that Akana, formerly SOA Software, has been named “Bronze Sponsor” of SYS-CON's 16th International Cloud Expo® New York, which will take place June 9-11, 2015, at the Javits Center in New York City, NY. Akana’s comprehensive suite of API Management, API Security, Integrated SOA Governance, and Cloud Integration solutions helps businesses accelerate digital transformation by securely extending their reach across multiple channels – mobile, cloud and Internet of Things. Akana enables enterprises to share data as APIs, connect and integrate applications, drive part...
    Cloud is not a commodity. And no matter what you call it, computing doesn’t come out of the sky. It comes from physical hardware inside brick and mortar facilities connected by hundreds of miles of networking cable. And no two clouds are built the same way. SoftLayer gives you the highest performing cloud infrastructure available. One platform that takes data centers around the world that are full of the widest range of cloud computing options, and then integrates and automates everything. Join SoftLayer on June 9 at 16th Cloud Expo to learn about IBM Cloud's SoftLayer platform, explore se...