Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

An Introduction to WebLogic Server Clustering

An Introduction to WebLogic Server Clustering

This is the second in a series of three articles discussing the clustering capabilities of BEA WebLogic Server 6.1 (WLS). This month we discuss replica-aware stubs, their impact on a clustered system, and how they're used with EJBs.

How WebLogic Can Instrument EJBs
WebLogic can provide clustering logic for an EJB in four possible locations (see Figure 1):

  1. The JNDI naming server, where the home stub is bound
  2. The container
  3. The home stub
  4. The remote stub

The home stub and the remote stub are the most interesting aspects, since both of these objects are downloaded by a Java client and run within the JVM affiliated with the client, not the application server.

WebLogic can develop load balancing and failover algorithms for EJBs not even resident in their own server! Given all of the locations where WebLogic can instrument one form of load-balancing or failover logic, the permutation of options is enormous.

Let's examine one-by-one what a WebLogic server instruments:

JNDI Naming Server
The JNDI naming server is the initial access point for all clients to retrieve a home stub of a session or entity bean. This doesn't apply for EJB 2.0 message-driven beans, however - they take a message-oriented middleware approach. To make EJBs highly available, WebLogic can easily replicate naming servers across nodes in the cluster. Since the home stubs placed into the naming tree are lightweight and serializable, it's easy for WebLogic to synchronize the trees in a cluster so that all of the servers provide a single, joint naming tree to their clients. Developers may choose to make their EJB container available on one server in the cluster or on all servers in the cluster. In the former scenario, the home stub replicated throughout the naming server has a hard coded reference to the home skeleton on the host server. In the latter scenario, the replicated home stub can reference the home skeleton on a different node. In Figure 1, this is represented by Node A.

Note: This doesn't encapsulate initial access logic. Replicated naming servers make the home stubs of EJBs highly available to all clients, but distributed systems will still require some form of initial access logic that load-balances JNDI InitialContext requests to the different servers in the cluster. WebLogic recommends using DNS round-robining, a proxy server, or some hardware local director. All of these technologies give you the ability to represent an entire cluster through a single IP address or DNS name. Each one internally maintains a table of IP addresses and servers that are participating in the cluster and then routes "new" requests using a load-balancing algorithm. Subsequent requests may be re-routed to the server that handled the initial request, depending upon the type of request and the technology used.

WebLogic can provide some load balancing and failover logic directly within the container. WebLogic does stateful session bean replication to provide minimal failover capability. When a stateful session bean is created, a backup copy can be placed on another server in the same cluster. The backup copy isn't used unless the primary fails, at which point the backup becomes the primary and nominates another backup. Every time a transaction on a stateful session bean commits, the bean is synchronized with its backup to ensure that both locations are current. If the container ever has a system failure and loses the primary, the remote stub of the bean fails over to the secondary server and uses the instance that's located there. Stateful session bean replication is a highly desirable feature since it provides noninterruptible access to some business logic. It isn't designed, however, to provide persistent access to data, since simultaneous failure of the primary and backup servers cannot be recovered. Entity beans should always manage persistent data. Node C in Figure 1 represents this.

Home Stub
This object is the first object accessed by remote clients and runs locally on a client's virtual machine (VM). Since EJB compilers generate stubs and skeletons at deployment time, the underlying logic in a stub can be WebLogic-specific. WebLogic can instrument some method-level load balancing and failover schemes directly in the stub. Since the primary action of the home stub is to create or load beans on a remote server, the server in which a bean is ultimately created isn't important. Effectively, every create(...) and findXXX(...) method could load-balance requests to a different home skeleton in the cluster. Node D in Figure 1 represents this.

Remote Stub
The remote stub is instantiated by the home skeleton and returned back to the client. It can perform the same types of load balancing and failover that a home stub can, but WebLogic has to be careful about when it chooses to do so. For instance, if a client has created an entity bean, it's likely that the entity bean will only exist in one server in the cluster. It's too expensive to have the contents of the same primary key active on multiple servers in the cluster if there are not multiple clients all requesting the same entity bean. To increase performance, WebLogic will likely only want to load entity beans in memory lazily when clients request their services. A remote stub that accesses an entity bean cannot freely load balance its requests to other servers in the cluster since the entity bean will only be active on a single server. Essentially, the remote stub is "pinned" to the server that it came from and isn't free to load balance at will. Node E in Figure 1 represents this.

Note: WebLogic Server 6.1 implements the latest version of the EJB 2.0 specification (EJB 2.0 PFD 2, 4/25/01). This version introduced local interfaces, special interfaces that allow a client colocated in the same VM as the EJB to access the EJB using pass-by-reference semantics instead of pass-by-value semantics. This gives a client a performance boost and a more robust object model, since local interfaces can have non-serializable interfaces. However, load balancing and failover of requests for EJBs can only be done for clients not co-located in the same VM. If an EJB container were to fail, it's likely that the entire VM hosting the server would fail as well. This would imply that any local clients would not be available and they subsequently couldn't failover to a container on another server. As a result of this behavior, WebLogic Server doesn't provide load balancing or failover of requests for local clients. Only remote clients can use the load balancing and failover features of WebLogic Server EJBs.

Replica-Aware Stubs
This RMI stub load balancing technology occurs in other places besides EJBs. It uses it to implement JDBC DataSource, JMS Connection Factory, JMS Topic, and JMS Queue objects. All of these objects are implemented as RMI stubs that are "replica-aware" - i.e. stubs that can load balance invocations to different servers hosting the service. For example, the JMS ConnectionFactory interface has a getConnection() method. Since the WebLogic ConnectionFactory is implemented as an RMI stub, subsequent calls to getConnection() will be load-balanced across different servers in the cluster as long as the client is a remote client. This behavior applies to all of technologies listed here.

Stateless Session EJBs
The simplest form of load balancing and failover for EJBs occurs with stateless session EJBs. This section discusses how load balancing, failover, and configuration work (see Figure 2).

Load Balancing
Since all instances of a stateless session bean type are identical, a home or remote stub can have its request serviced by any available object in any server. As long as the request gets handled, the remote stub has no preference as to whether the instance on the first server or the second server handles it.

WebLogic provides a better level of scalability by configuring home stubs and remote stubs to load balance method invocations across servers. Each method call handled by a stub would execute a "ServerChooser" algorithm in the stub to select the server best suited for handling this method invocation. The ServerChooser would return the IP address or connection to the server best meeting the criteria needed for this method invocation, and the stub would then forwards the invocation to that server.

Since all stateless session EJBs are identical, the home and remote stubs have a lot of flexibility in selecting which server should handle particular requests. WebLogic provides some basic load-balancing algorithms:


  • Random: A seed-based, random selection of a server to handle a request. This model can incorporate statistical irregularities over the short term.
  • Round Robin: This popular algorithm sends requests to different servers in a statistically regular way.
  • Weighted Round Robin: A derivative of round robin that favors certain servers, using ratios. Administrators and developers apply relative weights to different servers that determine how much of the load they should handle. One design pattern used in some production systems is to set to zero the weight of a server that needs to be brought down for maintenance, thus eliminating any EJB traffic to that server.
  • Programmatic: You code your own stub-based balancing algorithm as a Java class that's compiled into the stub implementation. The class has a single method that's executed whenever a remote or home stub has to select a server. The method you implement will typically have access to reflection method and input arguments that relate to the method the client invoked. From this information, the method you implement needs to programmatically generate a list of servers or IP addresses of servers to try when the stub needs to load-balance. The order of the list you generate dictates the order of the balancing scheme applied by the stub. This particular algorithm is a great way to implement a staging, test, and production environment for your EJBs. Depending upon the values of the input parameters or the current value of a flag specified in a text file, your programmatic filter can alter requests to different servers depending upon whether you're testing an application or running it in production mode.

    Fault Tolerance
    Load balancing sounds pretty easy to incorporate, doesn't it? Well, for the most part, it is. However, incorporating fault tolerance and failover of your EJB applications is a little bit trickier. There are two main things that an application vendor has to determine to accomplish a successful failover (and to be able to support fault tolerance).

    First, how does a home or remote stub determine if a failure situation has occurred? If an exception is generated, how does a stub know that the exception is a failure condition that cannot be recovered? There are three types of exceptions that a stub can receive: application exceptions (those defined by the bean developer), system exceptions (typically in the form of an EJBException), and network/communication exceptions. Application and system exceptions are clearly defined in the EJB specification and typically are propagated to the invoking client to be handled. Network/communication exceptions such as SocketException, CommunicationException, and others, indicate a much more dire, unable-to-communicate-with server scenario. An application server vendor's stub can intercept all system and communication exceptions and perform a failover to another server - if they can determine that it is safe to do so. Why wouldn't it be safe for them to perform this failover action? Read on for the answer!

    The second main consideration is: At what point in the invocation did the failure occur? There are three possible situations that the stub must address:

    1. The failure occurred before the server-side invocation started. This is a great situation for the stub to be in. If it can determine that a failure occurred after the method request was sent but before it was invoked on the server, the stub can treat this failure as a load-balance scenario and redirect the method invocation to any other available server.

    2. The failure occurred after the server-side invocation completed, but before the response message was properly propagated to the client. This is also a great situation for the stub to be in because it requires no further action.

    3. The failure occurred during the server-side invocation. This presents a sticky situation for the stub. The method that was invoked on the server may or may not have altered some server-side resources that impact future behavior of the system. If the stub makes a subsequent request on a method that impacts server-side resources or data, the stub may inadvertently perform the same altering action twice in a row during a failure recovery, which would cause the system to have indeterminate behavior! If the method doesn't perform any of these altering actions then it could safely invoke the method again; if it does alter the system, it can't.

    Unfortunately, it's very difficult for a stub to positively determine that the system is in either of those states. As a result, if a failure situation occurs, a stub will likely have to assume that the server was in the worst-case scenario (i.e., 3) - even if in reality it was in one of the happier scenarios. So, how's this resolved? WebLogic supports the concept of "idempotence" for methods. An idempotent method is one that yields the same result on subsequent invocations if the same input arguments are passed in. A non-idempotent method is one that alters the state of the system (yields different results) on subsequent executions.

    Types of methods that are idempotent include:


  • Any method that acts as a "reader/getter" method
  • Any method that performs a nonaltering query
  • Any method that accesses a resource manager, but leaves the state of the resource manager unaltered

    As a bean developer, you're aware of the behavior that the methods you write will have on a system. You are responsible for specifying which methods in your bean are idempotent and which are not. At runtime, WebLogic can freely perform a failover switch during a failed method invocation if the method that was being executed is idempotent. After all, if the method doesn't alter the state of the system, then the stub is confident that the existing system is intact and that a new invocation won't have any odd side effects. In situations where a failure situation occurs on a method that is idempotent, the stub will be forced to throw the communication exception that it receives to the client. Your client application will then have to decide whether or not it should try another invocation:


    try {
    MyHome home = (MyHome) ctx.lookup("MyEJB");

    // This should use PortableRemoteObject.narrow().
    My remote = (My) home.create();

    } catch (javax.naming.CommunicationException exception) {

    // This is a type of Naming Exception
    // This is an acceptable exception for me.
    Calling this method again
    // will not adversely impact the system.

    try {
    } catch (java.io.IOException exception) {

    // This must be some sort of socket exception.
    // I don't want to call this method again, so now
    it must be
    // handled in another way that you determine!


    Making a stateless session EJB support load balancing and failover is quite simple. You don't have to change the way you develop the bean. Rather, all configuration is done in the weblogic-ejb-jar.xml deployment descriptor (see Listing 1).

    Stateful Session EJBs
    Now let's examine how load balancing, failover, and configuration work in stateful session EJBs.

    Load Balancing
    With stateful session EJBs, a client is "pinned" to the server object it creates. As a result of this pinned nature of clients to instances, remote stubs are wired to a particular server that contains the instance the client is referring to. WebLogic provides no load balancing of remote method invocations as a result of this behavior.

    However, WebLogic does provide load balancing of remote home method invocations for stateful session EJBs. Since a home.create(...) merely creates an instance on a server, it doesn't matter which server the instance gets created on. WebLogic uses a load-balancing algorithm to direct different invocations to different servers as a result.

    In order for failover to be successful with stateful session EJBs, the state of the stateful session EJB must be located on another machine. WebLogic supports primary/secondary replication of stateful session EJBs to support failover of remote method invocations. A primary stateful session EJB instance is stored in the server where the EJB is created. The container will replicate the instance to a secondary server. If the server that hosts the primary instance becomes unavailable, remote method invocations will be redirected to the server with the secondary instance. The secondary instance will then become the primary and nominate another server to host the secondary instance. The remote stub maintains the IP addresses of the servers that host the primary and secondary instances.

    Just as with stateless session EJBs, all configuration of stateful session EJBs is done in the weblogic-ejb-jar.xml deployment descriptor (see Listing 2).

    Entity Beans
    Now let's look at entity beans, starting with cluster-aware home stubs. Then we can consider read-write entity beans, read-only entity beans, and how to get the best of both worlds by implementing the read-mostly pattern.

    Cluster-Aware Home Stubs
    Just like stateful and stateless session beans, entity beans can have cluster-aware home stubs. This allows for lifecycle methods to be distributed amongst the server instances in a cluster. For example, load balancing can be attributed to the database record creation, deletion, and query functionality behind the create(), remove(), and findXXX() methods defined in the bean's home interface. The EJB 2.0 specification introduced the concept of home methods, business functionality that can be attributed to groups of database records, rather than a single record. Calls to these home methods can be load balanced through the cluster-aware home stubs. As with session beans, an entity bean's home stub is made cluster-aware by setting to true the appropriate home-is-clusterable tag in the weblogic-ejb-jar.xml file.

    Read-Write Entity Beans
    The caching strategy selected for a given entity bean determines the possible clustering behavior of the bean's remote stub. Setting the value for the appropriate cache-strategy tag in the weblogic-ejb-jar.xml file configures this behavior. By default, entity beans are deployed with a read-write caching strategy, allowing clients to use the beans to edit database records. Creating or finding a read-write bean returns a remote stub pinned to a single server, which means that load balancing and failover capabilities are restricted to the home stub. Since, in this situation, multiple beans representing the same underlying database record could simultaneously exist within the cluster, data integrity must be preserved by having each bean instance read from the database before each transaction and write to the database with each commit operation.

    Read-Only Entity Beans
    In situations where only data retrieval is necessary, entity beans can be deployed with a read-only caching strategy. Accessing a read-only bean returns a cluster-aware remote stub, which can load-balance on every business method call - thus improving scalability. In addition, the contents of read-only beans are cached on every host server to avoid database reads, further improving performance. In order to be classified as read-only, a candidate entity bean's methods must be idempotent.

    While EJB clients can't modify read-only entity beans, the data the beans represent can be changed by an external source. With regard to caching, a tradeoff must then take place between quick access to the data and maintaining the most current snapshot of the data. In WebLogic Server 6.1, two data update strategies are available: periodic updates or programmatic invalidation.

    The periodic update strategy is governed by the read-timeout-seconds deployment descriptor parameter. By setting this parameter in the weblogic-ejb-jar.xml file, the container will refresh the data stored in the bean by loading from the database at regular intervals. The advantage of this mechanism is that it's simple and requires no additional programming - all necessary configuration takes place in the deployment descriptor. However, this update mechanism does suffer from one efficiency flaw: the data is blindly loaded into the bean at regular intervals, even if a database update doesn't occur during the established time period.

    Programmatic invalidation overcomes this obstacle, adding intelligence to the update of read-only beans. A developer can trigger a refresh of a single bean instance or group of instances of a certain bean class by invoking an invalidate() method, available through the home interface. When the invalidate() method is called, the WebLogic EJB container will invalidate the appropriate beans on the local server and send a multicast message to all other servers in the cluster to do likewise.

    The added control over when a bean gets updated comes with a small price, however. In order to invoke the invalidate methods, the EJB client must explicitly cast the bean's home stub to either the weblogic.ejb.CachingHome or weblogic.ejb.LocalCachingHome interface (the latter for entity beans whose clients are other EJBs resident in the same instance of WebLogic). These interfaces are BEA proprietary extensions, filling in a performance hole in the current specification. The potential improvement in data access performance mitigates the minor inconvenience of removing such method invocations in the event of migrating the EJB client to another application server environment.

    Applying the Read-Mostly Pattern
    What about entity beans that require occasional programmatic updates? Is there a way to cash in on the performance benefits of read-only beans while still providing write access? Yes: the answer lies in the implementation of the read-mostly pattern, by deploying the same bean class twice - once each with read-only and read-write caching strategy tags. Clients of the read-only bean can benefit from load-balanced access to cached data, while clients of the read-write bean can rely on data integrity during transactions.

    If you're relying on syncing read-only beans with periodic updates, via the read-timeout-seconds para-meter, we'd make the following recommendations:


  • Set all values of read-timeout-seconds to the minimum acceptable values that provide frequent enough updates without sacrificing performance - appropriate selection may be an iterative process for a given application.
  • If the data behind several classes of read-only beans could be updated in a single transaction, make sure to set all corresponding values for read-timeout-seconds identically.
  • Minimize the amount of data updated in the read-write beans and test to make sure that the transactions in which they're involved don't extend past the update intervals of their corresponding read-only beans.

    Certainly, to avoid this optimization process developers can choose the programmatic invalidation mechanism described above. However, this practice would reduce EJB portability since the bean implementation class would contain calls to proprietary WebLogic interfaces.

    A third option, available when using container-managed persistence, is the use of the invalidation-target parameter when configuring the read-write bean in the weblogic-ejb-jar.xml deployment descriptor file. By specifying the name of the corresponding read-only bean within this tag, that read-only bean will be automatically invalidated when the read-write bean is updated. In other words, invalidation-target provides developers with an optimal refresh strategy for read-only beans without sacrificing code portability.

    The weblogic-ejb-jar.xml deployment descriptor file shown in Listing 3 illustrates the appropriate settings for an entity bean deployed with the read-mostly strategy.

    While the concepts behind EJB clustering take some time to digest, the mechanism for implementing load balancing and failover in WebLogic-based enterprise applications is distilled down to setting a few tags within the deployment descriptor files. Certainly, determining the optimal settings for those parameters that are suitable for a given application is an iterative process. However, by isolating clustering behavior to configuration files, WebLogic minimizes the time necessary to reach that level of optimization.

    In the next installment of this series, we'll discuss common architectural practices for tying together presentation and business logic in a clustered environment.

  • More Stories By Tyler Jewell

    Tyler Jewell is VP, Product Management & Strategy, Oracle Public Cloud.

    More Stories By Lawrence Kaye

    Lawrence Kaye is the Manager of Delivery Strategy in BEA Educational Services. He has five years of Java development experience and has taught WLS development and administration courses for the past two years. Lawrence can be reached at [email protected]

    Comments (0)

    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.

    @ThingsExpo Stories
    DX World EXPO, LLC, a Lighthouse Point, Florida-based startup trade show producer and the creator of "DXWorldEXPO® - Digital Transformation Conference & Expo" has announced its executive management team. The team is headed by Levent Selamoglu, who has been named CEO. "Now is the time for a truly global DX event, to bring together the leading minds from the technology world in a conversation about Digital Transformation," he said in making the announcement.
    "Space Monkey by Vivent Smart Home is a product that is a distributed cloud-based edge storage network. Vivent Smart Home, our parent company, is a smart home provider that places a lot of hard drives across homes in North America," explained JT Olds, Director of Engineering, and Brandon Crowfeather, Product Manager, at Vivint Smart Home, in this SYS-CON.tv interview at @ThingsExpo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
    SYS-CON Events announced today that Conference Guru has been named “Media Sponsor” of the 22nd International Cloud Expo, which will take place on June 5-7, 2018, at the Javits Center in New York, NY. A valuable conference experience generates new contacts, sales leads, potential strategic partners and potential investors; helps gather competitive intelligence and even provides inspiration for new products and services. Conference Guru works with conference organizers to pass great deals to gre...
    The Internet of Things will challenge the status quo of how IT and development organizations operate. Or will it? Certainly the fog layer of IoT requires special insights about data ontology, security and transactional integrity. But the developmental challenges are the same: People, Process and Platform. In his session at @ThingsExpo, Craig Sproule, CEO of Metavine, demonstrated how to move beyond today's coding paradigm and shared the must-have mindsets for removing complexity from the develop...
    In his Opening Keynote at 21st Cloud Expo, John Considine, General Manager of IBM Cloud Infrastructure, led attendees through the exciting evolution of the cloud. He looked at this major disruption from the perspective of technology, business models, and what this means for enterprises of all sizes. John Considine is General Manager of Cloud Infrastructure Services at IBM. In that role he is responsible for leading IBM’s public cloud infrastructure including strategy, development, and offering m...
    "Evatronix provides design services to companies that need to integrate the IoT technology in their products but they don't necessarily have the expertise, knowledge and design team to do so," explained Adam Morawiec, VP of Business Development at Evatronix, in this SYS-CON.tv interview at @ThingsExpo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
    To get the most out of their data, successful companies are not focusing on queries and data lakes, they are actively integrating analytics into their operations with a data-first application development approach. Real-time adjustments to improve revenues, reduce costs, or mitigate risk rely on applications that minimize latency on a variety of data sources. In his session at @BigDataExpo, Jack Norris, Senior Vice President, Data and Applications at MapR Technologies, reviewed best practices to ...
    Widespread fragmentation is stalling the growth of the IIoT and making it difficult for partners to work together. The number of software platforms, apps, hardware and connectivity standards is creating paralysis among businesses that are afraid of being locked into a solution. EdgeX Foundry is unifying the community around a common IoT edge framework and an ecosystem of interoperable components.
    Large industrial manufacturing organizations are adopting the agile principles of cloud software companies. The industrial manufacturing development process has not scaled over time. Now that design CAD teams are geographically distributed, centralizing their work is key. With large multi-gigabyte projects, outdated tools have stifled industrial team agility, time-to-market milestones, and impacted P&L stakeholders.
    "Akvelon is a software development company and we also provide consultancy services to folks who are looking to scale or accelerate their engineering roadmaps," explained Jeremiah Mothersell, Marketing Manager at Akvelon, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
    "IBM is really all in on blockchain. We take a look at sort of the history of blockchain ledger technologies. It started out with bitcoin, Ethereum, and IBM evaluated these particular blockchain technologies and found they were anonymous and permissionless and that many companies were looking for permissioned blockchain," stated René Bostic, Technical VP of the IBM Cloud Unit in North America, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Conventi...
    In his session at 21st Cloud Expo, Carl J. Levine, Senior Technical Evangelist for NS1, will objectively discuss how DNS is used to solve Digital Transformation challenges in large SaaS applications, CDNs, AdTech platforms, and other demanding use cases. Carl J. Levine is the Senior Technical Evangelist for NS1. A veteran of the Internet Infrastructure space, he has over a decade of experience with startups, networking protocols and Internet infrastructure, combined with the unique ability to it...
    22nd International Cloud Expo, taking place June 5-7, 2018, at the Javits Center in New York City, NY, and co-located with the 1st DXWorld Expo will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud ...
    "Cloud Academy is an enterprise training platform for the cloud, specifically public clouds. We offer guided learning experiences on AWS, Azure, Google Cloud and all the surrounding methodologies and technologies that you need to know and your teams need to know in order to leverage the full benefits of the cloud," explained Alex Brower, VP of Marketing at Cloud Academy, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clar...
    Gemini is Yahoo’s native and search advertising platform. To ensure the quality of a complex distributed system that spans multiple products and components and across various desktop websites and mobile app and web experiences – both Yahoo owned and operated and third-party syndication (supply), with complex interaction with more than a billion users and numerous advertisers globally (demand) – it becomes imperative to automate a set of end-to-end tests 24x7 to detect bugs and regression. In th...
    "MobiDev is a software development company and we do complex, custom software development for everybody from entrepreneurs to large enterprises," explained Alan Winters, U.S. Head of Business Development at MobiDev, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
    Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection between Coke and its customers. Digital signs pair software with high-resolution displays so that a message can be changed instantly based on what the operator wants to communicate or sell. In their Day 3 Keynote at 21st Cloud Expo, Greg Chambers, Global Group Director, Digital Innovation, Coca-Cola, and Vidya Nagarajan, a Senior Product Manager at Google, discussed how from store operations and ...
    "There's plenty of bandwidth out there but it's never in the right place. So what Cedexis does is uses data to work out the best pathways to get data from the origin to the person who wants to get it," explained Simon Jones, Evangelist and Head of Marketing at Cedexis, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
    SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
    SYS-CON Events announced today that Telecom Reseller has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5-7, 2018, at the Javits Center in New York, NY. Telecom Reseller reports on Unified Communications, UCaaS, BPaaS for enterprise and SMBs. They report extensively on both customer premises based solutions such as IP-PBX as well as cloud based and hosted platforms.