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
    Organizations planning enterprise data center consolidation and modernization projects are faced with a challenging, costly reality. Requirements to deploy modern, cloud-native applications simultaneously with traditional client/server applications are almost impossible to achieve with hardware-centric enterprise infrastructure. Compute and network infrastructure are fast moving down a software-defined path, but storage has been a laggard. Until now.
    Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
    Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
    IoT is at the core or many Digital Transformation initiatives with the goal of re-inventing a company's business model. We all agree that collecting relevant IoT data will result in massive amounts of data needing to be stored. However, with the rapid development of IoT devices and ongoing business model transformation, we are not able to predict the volume and growth of IoT data. And with the lack of IoT history, traditional methods of IT and infrastructure planning based on the past do not app...
    "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.
    DXWorldEXPO LLC, the producer of the world's most influential technology conferences and trade shows has announced the 22nd International CloudEXPO | DXWorldEXPO "Early Bird Registration" is now open. Register for Full Conference "Gold Pass" ▸ Here (Expo Hall ▸ Here)
    More and more brands have jumped on the IoT bandwagon. We have an excess of wearables – activity trackers, smartwatches, smart glasses and sneakers, and more that track seemingly endless datapoints. However, most consumers have no idea what “IoT” means. Creating more wearables that track data shouldn't be the aim of brands; delivering meaningful, tangible relevance to their users should be. We're in a period in which the IoT pendulum is still swinging. Initially, it swung toward "smart for smart...
    IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
    Here are the Top 20 Twitter Influencers of the month as determined by the Kcore algorithm, in a range of current topics of interest from #IoT to #DeepLearning. To run a real-time search of a given term in our website and see the current top influencers, click on the topic name. Among the top 20 IoT influencers, ThingsEXPO ranked #14 and CloudEXPO ranked #17.
    Join IBM November 1 at 21st Cloud Expo at the Santa Clara Convention Center in Santa Clara, CA, and learn how IBM Watson can bring cognitive services and AI to intelligent, unmanned systems. Cognitive analysis impacts today’s systems with unparalleled ability that were previously available only to manned, back-end operations. Thanks to cloud processing, IBM Watson can bring cognitive services and AI to intelligent, unmanned systems. Imagine a robot vacuum that becomes your personal assistant tha...
    As data explodes in quantity, importance and from new sources, the need for managing and protecting data residing across physical, virtual, and cloud environments grow with it. Managing data includes protecting it, indexing and classifying it for true, long-term management, compliance and E-Discovery. Commvault can ensure this with a single pane of glass solution – whether in a private cloud, a Service Provider delivered public cloud or a hybrid cloud environment – across the heterogeneous enter...
    The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
    DXWorldEXPO LLC announced today that ICC-USA, a computer systems integrator and server manufacturing company focused on developing products and product appliances, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City. ICC is a computer systems integrator and server manufacturing company focused on developing products and product appliances to meet a wide range of ...
    Major trends and emerging technologies – from virtual reality and IoT, to Big Data and algorithms – are helping organizations innovate in the digital era. However, to create real business value, IT must think beyond the ‘what’ of digital transformation to the ‘how’ to harness emerging trends, innovation and disruption. Architecture is the key that underpins and ties all these efforts together. In the digital age, it’s important to invest in architecture, extend the enterprise footprint to the cl...
    DXWorldEXPO LLC announced today that All in Mobile, a mobile app development company from Poland, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. All In Mobile is a mobile app development company from Poland. Since 2014, they maintain passion for developing mobile applications for enterprises and startups worldwide.
    In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and ...
    "We are a well-established player in the application life cycle management market and we also have a very strong version control product," stated Flint Brenton, CEO of CollabNet,, in this SYS-CON.tv interview at 18th Cloud Expo at the Javits Center in New York City, NY.
    In his session at @ThingsExpo, Arvind Radhakrishnen discussed how IoT offers new business models in banking and financial services organizations with the capability to revolutionize products, payments, channels, business processes and asset management built on strong architectural foundation. The following topics were covered: How IoT stands to impact various business parameters including customer experience, cost and risk management within BFS organizations.
    While the focus and objectives of IoT initiatives are many and diverse, they all share a few common attributes, and one of those is the network. Commonly, that network includes the Internet, over which there isn't any real control for performance and availability. Or is there? The current state of the art for Big Data analytics, as applied to network telemetry, offers new opportunities for improving and assuring operational integrity. In his session at @ThingsExpo, Jim Frey, Vice President of S...
    With the introduction of IoT and Smart Living in every aspect of our lives, one question has become relevant: What are the security implications? To answer this, first we have to look and explore the security models of the technologies that IoT is founded upon. In his session at @ThingsExpo, Nevi Kaja, a Research Engineer at Ford Motor Company, discussed some of the security challenges of the IoT infrastructure and related how these aspects impact Smart Living. The material was delivered interac...