Click here to close now.

Welcome!

Websphere Authors: Carmen Gonzalez, ScriptRock Blog, Pat Romanski, Yeshim Deniz, Elizabeth White

Related Topics: Websphere

Websphere: Article

Automated Deployment of Enterprise Application Updates

Part 1 - Basic concepts

This two-part article discusses application deployment, particularly automated updates, to IBM WebSphere Application Servers in a large-scale enterprise environment. It applies to versions 5.0, 5.1, and 6.0, and also includes an introduction to a few version 6.0 enhancements. This article is not intended to be used as a reference for all the details of WebSphere Application Server administration, but it does describe the key concepts used, and contains a list of references. Although the beginning of the article reviews some fairly basic base server and managed server concepts and operations, much of the remainder of the article will discuss certain complex concepts or operational considerations that will be new even to very experienced enterprise application server administrators.

Part 1 discusses wsadmin deployment to base and managed servers. It also discusses why phased deployments are needed to maintain applications in a WebSphere Application Server Network-Deployment managed cell, and how to maintain high availability in such an environment.

Part 2 of the article will discuss pre- and post-deployment validation and gradual deployment of incompatible versions of applications. It will also discuss the design and implementation of a downloadable Automated Deployment example program that illustrates how to automate the deployment of randomly built collections of enterprise applications or updates, and how to automatically target those applications or updates to the correct servers, including stage-specific application setup.

The Problem
It is quite easy to deploy (install) an application into a WebSphere Application Server setup - typically it just takes a one-line command. For your local running base server, it can be as simple as:

wsadmin -c "$AdminApp install X:/MyApp.ear" -lang jacl

However, this simplicity is deceiving and the preceding example is really just the "Hello World" of deployment - a nice demo, but not typical of the real world.

In a real enterprise environment, there are hundreds of interrelated applications spread over dozens of remote application servers, and regular updates that need to be deployed to the right servers, all the while maintaining application availability to users. Even worse, most large enterprises have different sets of operating environments, or stages, each requiring different setups for the same application. For example, the security role mappings and the database used for a specific application in a Microsoft Windows integration stage are likely different from those used for that same application on a Linux production server.

The result might be that at 3 a.m. when some random group of 20 applications has just been rebuilt because of an automated production build of Source Code Management (SCM) code changes, those particular 20 applications each needs to have its updates deployed to its correct individual application server somewhere in the enterprise. And, although it is 3 a.m. in North America, it is prime time elsewhere in the world, so the application updates need to be done in a way that maintains high application availability. This update build and deployment process is regularly repeated, each time involving a randomly different set of updated applications.

Command Line wsadmin and JACL/Jython Scripts
WebSphere Application Server has an extensive administration program, the Administration Console. It also has an equivalent command-line tool, wsadmin, which can be run interactively and which accepts a file of scripted commands. For scripting, wsadmin supports the two script languages JACL and Jython. (See the reference section for links to related material.) In the examples in this article, and in the downloadable example program, JACL is used since it runs on version 5.0 and above (Jython runs on version 5.1 and above).

This article is not intended as a reference for WebSphere administration or the wsadmin tool. For more detailed information, consult the material in the reference section.

Local Base Server Deployment
The simplest deployment scenario is to install an application from a build machine to a local running base server (Network Deployment managed cells are discussed a little later in this article). The local WebSphere Application Server installation has a bin directory containing the wsadmin command and other tools.

The typical sequence for an initial application installation is:
1.  If the local server is not already running, then start it:

startServer server1

2.  Install the application:

wsadmin -c "$AdminApp install C:/MyApp.ear" -lang jacl

3.  Optionally list all current installed applications (to verify that it really was installed):

wsadmin -c "$AdminApp list" - lang jacl

4.  Save this new server configuration:

wsadmin -c "$AdminConfig save" -lang jacl

5.  Start the application (this is a one-line command):


wsadmin  -c  "$AdminControl
  invoke
    [$Admi  nControl  queryNames
    type=ApplicationManager,*]
startApplication  MyAppName"  -
  lang  jacl

The typical sequence for an uninstallation using a script file instead of interactive commands is:

wsadmin -f uninstall.jacl - lang jacl

where the file uninstall.jacl contains the following lines:


$AdminApp  list
set  appMgr  [$AdminControl
  queryNames  type=Application
  Manager,*]
$AdminControl  invoke  $appMgr
  stopApplication  MyAppName
$AdminApp  uninstall  MyAppName
$AdminApp  list
$AdminConfig  save

Note that the default wsadmin server connection type SOAP requires a running server. It is possible to connect using connection type NONE, but the available operations are restricted. Refer to wsadmin documentation for more details.

Remote Base Server Deployment
A slightly more typical environment is one where one or more target base servers are on remote machines. The most obvious approach (and the one used by some customers) is to use File Transfer Protocol (FTP) to transfer the application or update from their build machine to the remote target machines, and then to use telnet, or some other similar program, to run the wsadmin program on those remote machines. This works, but it is quite messy. It requires FTP and telnet on each remote machine and quite a few error-prone manual operations. It also requires FTP and telnet accounts on each remote machine, which introduces administration and security issues many companies would prefer to avoid.

WebSphere Application Server provides a nice solution to this scenario that many users are not even aware exists. If you install WebSphere on the build machine, then the WebSphere Application Server runtime and its wsadmin command tool are available even if that installation server is never configured or started. You can then use the wsadmin command to connect to your remote target servers and run your deployment commands against those remote servers. If a local build machine file is being installed on the remote server, WebSphere Application Server will internally do the file transfer for you. All the normal WebSphere security (if configured) is automatically used according to the userID and password used with the wsadmin tool. Thus, deployment to remote servers is as easy as to a local server; the only difference is that the wsadmin invocation command specifies a remote server instead of a local one:

Wsadmin -host MyRemoteHost -port MyRemotePort ...commands...

Note: The above solution for remote base server deployment only works if both the remote and local installation (where wsadmin is running) are WebSphere Application Server version 6 installations. If either is a version 5.0 or version 5.1 installation, then you will get an error "X:\MyTEMP\appnnnnn.ear does not exist for installation." Base Server (nonmanaged server) Remote File Transfer support is a version-6 enhancement - unfortunately, the version-5x error is not clear about that.

Figure 1 shows a very simple, but representative, base server organization.

This approach provides a nice solution for a build machine and one or two remote base servers. But as the number of independent base servers increases, it rapidly becomes desirable to have centralized administration to manage the collection of servers as a single administrative cell.

Network Deployment Managed Cells, Nodes, and Clusters
As the number of applications and the number of target servers grows, it becomes almost essential to provide single administrative control for these large collections.

A node is a physical collection of one or many application servers on a particular machine, and typically there is one Node Agent per node controlling those servers on that remote machine. Why should there be more than one server per machine? In addition to the obvious redundancy consideration, there are technical and performance reasons (such as Java threading limitations, Java memory garbage collection considerations, etc.) why splitting one larger server into multiple servers can provide significant performance improvements on that same machine. This is particularly common on very large and highly reliable server platforms. For details, see the WebSphere Application Server performance "Best Practices" documents. Note that there can be two or more logically separate nodes (each with its own servers) on the same physical machine, but that is very unusual.

Why should there be more than one target machine? In addition to the obvious ability to supply additional resources (additional CPU cycles, physical memory, etc.) and to provide physical redundancy against hardware failure, there may be organizational or geographical requirements. As well, the various Quality Assurance (QA) environments, such as development, integration, test, pilot-production, and production are almost always run on different machines for logistic, administrative, and security reasons.

To simplify the setup and ongoing administration of redundant servers, most application server products introduce the concept of clusters. A cluster is a logical collection of servers each, of which typically contains the same set of applications. (Any one cluster member could actually contain additional or different programs, but that is highly unusual and confusing.) A vertical cluster contains multiple cluster members on the same node, while a horizontal cluster contains cluster members on different nodes (which is more typical).

A managed "cell" is an administrative collection of many servers. One of the key features of WebSphere Application Server Network Deployment is that groups of servers can be federated together into a single managed cell. A special server called the Deployment Manager (DMgr) manages all the servers and applications in the cell using one Node Agent (NA) per node to control the one or more servers in that node. Node Agents are typically configured as always-running "daemons" within their host machine operating system, so they are always available. They can start or stop servers on that machine, install or uninstall applications on the servers, and can configure other server settings and control other server functions.

Figure 2 shows a very simple, but representative and scalable cell organization.

Using wsadmin with Managed Servers (-conntype SOAP)
In our earlier discussion about using wsadmin to deploy to a local running base server, you probably assumed (correctly) that the wsadmin program connected to that server to perform its various administrative operations. We also could have started wsadmin specifying the default connection parameter type of -conntype SOAP (or RMI). If the local server is not running, we can start wsadmin with -conntype NONE and then wsadmin will directly manipulate the local server configuration files and their contents. In this case, there is less functionality available and some of the commands (like starting an application) are not available. In the case of remote base servers, we supplied a host and port parameter to specify which running server to connect to, so clearly it is not possible to use -conntype NONE for remote servers since the wsadmin program has no direct access to their (remote) configuration files.

In the case of managed servers (servers federated into a Network Deployment cell), determining what is happening is not quite as obvious. If the local server is configured as part of a managed cell, then by default the wsadmin program will connect to its Deployment Manager server and ask that Deployment Manager to perform the specified administrative operations against the specified target servers. Again, the default connection type is -conntype SOAP. For managed servers we can override the default destination and use the host and port parameters to connect to a Node Agent controlling one or more target servers, or to connect directly to a target server. Connecting to the Deployment Manager (the default option) gives the most functionality, to Node Agents a little less functionality, to servers even less functionality, and -conntype NONE to a local server gives the least functionality. It is highly recommended that you always connect to the Deployment Manager, otherwise localized changes might be incompatible with the master cell configuration (such as installing an application with the same name as is already installed elsewhere in the cell) and could cause subsequent synchronization errors. For details, consult the WebSphere Information Center documentation.

How do you have a build machine deploy to remote production servers? Earlier we said that you could have WebSphere Application Server installed on a build machine, without requiring a server to be actually configured or running. Therefore, you can just start wsadmin using the host and port parameters to specify the remote Deployment Manager for the production cell, and everything works as expected. Note that the Deployment Manager must always be at the same version (or a later one) plus service level as all of the servers within the cell.

Note that WebSphere Application Server version 6 provides support for multiple server "profiles" (an expanded implementation of version 5.1 instances), where each server profile is essentially a totally independent server (independent configurations sharing a common set of runtime programs). The wsadmin command will operate against its default server profile (determined by the profile location you are executing from), but you can use the parameter -profileName MyProfile to override that default and specify the actual server profile (and hence its particular Deployment Manager) to be used, or you can use the host and port parameters to directly specify the destination (typically a Deployment Manager).

Web Servers, Firewalls, Redundancy, and Workload Management
Note that there are typically one or more Web servers in front of the set of application servers. The Web servers accept incoming user HTTP requests and route each request to an appropriate application server to perform the work. Of course, one or more levels of firewall protection are almost always present at different locations within the system.

Figure 3 shows a simple, but representative HTTP organization.

Good Availability Using Redundancy and Server Failover
Looking after the design, setup, and operation of redundant systems is a significant activity, and there are whole books devoted to this topic. For detailed information, consult the material in the reference section.

If two or more application servers are hosting the same application, then such redundancy can provide workload sharing (better throughput and response time for increasing numbers of requests). This redundancy can also be used to provide reactive server failover and recovery in case of unexpected hardware or software failure. In case of an application server failure, WebSphere Application Server can be configured such that incoming Web server work requests are routed to a different server running that same application. All new requests are handled appropriately, but any in-progress HTTP session will be disrupted and must be reinitiated by users (it will appear to them that there was a brief service failure).

High Availability Using Server Failover and Session Recovery
WebSphere Application Server can reroute new work requests, but it can also be configured to provide reactive session recovery to allow most in-progress requests to continue and complete on the redundant server without any visible interruption to end users. Thus, high application availability can be achieved in spite of unexpected system failures. For most users, even in-progress HTTP sessions appear to continue without any visible interruption.

Continuous Availability Using Preemptive Work Rerouting ("Quiesce")
Even though many HTTP sessions can be recovered, applications with very large session data or other session data that cannot be persisted, can cause an in-progress HTTP session to fail. Thus, if an application or system has a planned outage (due to maintenance or other operator-initiated situations), then preemptive work rerouting can be used to provide nearly continuous availability.

The affected servers are first "quiesced," meaning that all new incoming work requests are routed instead to other redundant servers, and all in-progress HTTP sessions on the quiesced servers are temporarily allowed to run until completed. After a reasonable period of time the quiesced servers are stopped and the planned maintenance or other activity is performed. After the planned activity is completed, the servers are "re-activated." New incoming requests can again be routed to them (in addition to the other, still running, redundant servers).

Quiescing entire cells (as discussed a little later in the Gradual Rollout section) is typically done up front at the Network Dispatcher (IP Sprayer) level using products such as WebSphere Load Balancer. The Network Dispatcher must be configured with session affinity to ensure that all user requests from the same user HTTP session get routed to the same processing organization. Quiescing individual application servers is typically done at the HTTP Web server level by manipulating the routing table in the plugin-cfg.xml file. This file is checked for changes by the HTTP server once per minute, or at another specified frequency. The HTTP server must be similarly configured with session affinity. Note that WebSphere Application Server version 5 could generate the plugin-cfg.xml files, but they needed to be manually transferred to the HTTP servers. Version 6 has a new feature to allow its HTTP servers to be federated into a cell, and to transfer the plugin-cfg.xml files.

AutoSync Application Updates Throughout an Enterprise Cell
WebSphere Application Server has the ability to provide automated distribution of application updates to servers throughout a managed cell. The application update is first installed into the Deployment Manager application repository. If a Node Agent has its AutoSync feature enabled (which is the default setting), then that Node Agent will periodically (by default, every 60 seconds) perform a NodeSync, which asks the cell Deployment Manager for any application updates. Any such updates are then transferred to the Node Agent, and that Node Agent then updates all its affected servers (since it might have multiple servers that are configured to run the same application). Thus, if each Node Agent has the default AutoSync enabled, any application updated or installed into the Deployment Manager will be automatically distributed to every affected node and to every affected server on those nodes over a relatively short period of time.

Application Updates Can Cause Application Availability Failures
Some administrators fail to understand that default application updates can cause application availability failures even if their entire system is configured for server failover and session recovery. This is because while an application is being updated it is not available to process work requests, and any work routed to it from a Web server will not get a response. Even worse, any other interdependent application will have a service failure if it tries to use the unavailable application instance. This is because the Web servers and the workload management programs don't know that the application is temporarily unavailable. The solution is to first stop the affected application server before doing the application update (not just the application, the complete application server). The stopped application server will be detected, and server failover and session recovery will then take place as expected.

WebSphere Application Server version 6 has the improved ability to perform incremental in-place updates of application components, which will help improve application availability. However, certain types of application component updates will still require stopping and restarting the application, and thus can still result in application availability failures unless the servers are first stopped and server failover and session recovery are active, or unless preemptive work using quiesce and rerouting are performed.

Remember our earlier discussion of the AutoSync feature to automatically distribute application updates to all affected nodes in a cell? There is an availability issue that needs to be understood and handled. Each of the affected applications will be unavailable on its individual servers during the update. Even worse, if several Node Agents happen to request their NodeSync at the same time or at overlapping times, then the affected application on each of those affected nodes will be transferred and updated at essentially the same time, resulting in application unavailability on multiple nodes simultaneously! Where application availability is a serious concern, the solution is to specifically control the phased distribution of updates throughout the enterprise cell.

Better: Phased Distribution of a Single (Compatible) Application Update
As previously mentioned, a specifically controlled phased distribution of an application update (compatible with previous versions) throughout a cell will minimize application availability issues. The required sequence is as follows:

  1. Save the current setting and then disable AutoSync on all affected nodes:
    a. Can also optionally save and disable SyncOnStartup.
  2. Sequentially, for each affected node, phase-deploy the update:
    a. Select the next affected node to be updated.
    b. Optionally quiesce all of its affected servers (reroute new work requests).
    c. Stop all of its affected servers.
    d. NodeSync that node to retrieve the update and to install it in each affected server. Note: Wait to ensure the EAR expansion is complete.
    e. Restart the affected servers. Note: Test and wait to ensure the server is running.
    f. Optionally reactivate the affected servers (to process new work requests).
    g. Optionally validate installed application operation.
    h. Optionally request manual confirmation to accept (or reject and restore) this update.
    i. Repeat for the next affected node.
  3. Restore the previous AutoSync settings for all affected nodes:
    a. Including SyncOnStartup if it was optionally disabled.
The above process involves a lot of manual operation and is very error-prone. A script can be created to perform the specific steps, but a different script is required for each different application and each application's different set of associated target servers. The scripts can be quite complex and difficult to create, and require ongoing maintenance as the environment changes.

There are two special notes in the above steps. First, after performing the NodeSync, the application update (EAR) has been distributed down to the node, but the EAR file must still be expanded into the server installed application directory. Until this EAR expansion is complete, attempting to start the server will produce indeterminate results. An IBM Problem Report has been created about this, and there may, in the future, be a downloadable WebSphere Interim Fix to allow scripts to test for the completion of the EAR expansion. Second, after returning from the wsadmin startServer command, the command has been processed by the Node Agent, but the actual server startup may not yet be complete. Scripts need to test that the server has completed startup and is running.

Note that WebSphere Application Server version 6 has a new cluster-update feature to phase distribute an update to each of a cluster's members one node at a time, including the stopping and restarting of affected servers being updated. Where server failure and session recovery have been configured and provide sufficient functionality, very good high availability will be provided during cluster updates. This feature currently cannot be used to phase distribute an update to unclustered servers and does not do preemptive quiescing or reactivation of work rerouting. If multiple cluster members are on the same node (vertical clustering for scalability), then they will be simultaneously updated (and simultaneously unavailable) as if the Node Agent had performed a regular NodeSync.

Also WebSphere Application Server version 6 cluster updates can only be done for one application at a time. If multiple applications need to be updated within a cluster, then multiple cluster update operations must be individually performed, and each cluster member node and its affected servers will be cycled again during each individual cluster update.

In summary, the WebSphere Application Server version 6 new cluster-update feature is a convenient way to distribute a single update throughout a horizontal cluster with cluster members across multiple nodes, and it does so while maintaining high-availability.

Best: Phased Distribution of Multiple (Compatible) Application Updates
As just mentioned, a specifically controlled phased distribution of an individual application update helps maximize availability. However, if multiple application updates are required, with each application update targeted to a potentially different but overlapping set of enterprise servers, then the process is slightly more complex even though all the same basic principles apply. The sequence required is as follows:

  1. Analyze the set of all current updates to be deployed
  2. For each application, determine (read) its specific set of target nodes and servers
  3. From the total set of affected nodes and servers, calculate the subset of unique affected nodes and unique affected servers
  4. Perform the previously described phased distribution for each affected node
As for the phased deployment of single applications, the above process involves a lot of manual operation and is very error-prone. Additional scripts can be created to assist in these steps, but with ever-increasing numbers of different applications, target servers, and stage environment and applications settings, the number and complexity of specialized scripts becomes an enormous challenge to create and then to maintain.

Part 2: Deployment Validation, Gradual Deployment, Automated Deployment, and References
Part 1 covered the basics of deployment of enterprise application (EAR) updates throughout an enterprise cell. Part 2 will cover pre- and post-deployment validation, and gradual deployment (of incompatible versions of applications). It will also describe the "Automated Deployment" example program in detail, and will include an extensive set of references.

Resources
WebSphere Application Server Administration

  • IBM WebSphere Application Server Network Deployment V5.1: System Administration: ftp.software.ibm.com/software/webserver/appserv/library/wasv51nd_admin.pdf Ch-4: Welcome to Scripting, Ch-5: Deploying and Managing Using Scripting
  • Williamson, Leigh; Chan, Lavena; Cundiff, Roger; (et al.) (2004). ISBN-0131446045. IBMWebSphere System Administration
  • Barcia, Roland; Hines, Bill; Alcott,Tom; Botzum, Keys (2004). ISBN-0131468626. IBM WebSphere: Deployment and Advanced Configuration

    WSADMIN Scripting

  • WebSphere Application Server Information Center: Deploying and managing using scripting: http://publib.boulder.ibm.com/infocenter/wasinfo/ index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/trun_wlm.html
  • WebSphere Application Server Technical Library, Sample scripts: www.ibm.com/developerworks/websphere/library/samples/SampleScripts.html
  • RedBook: WebSphere Version 5 for z/OS - WSADMIN Primer: www.ibm.com/support/docview.wss?uid=tss1wp100421

    WebSphere Availability and Work-Load Management

  • Extreme Availability with WebSphere and DB2: www.ibm.com/websphere/developer/zones/hipods/
  • High Performance On Demand Solutions: www-128.ibm.com/developerworks/websphere/zones/hvws/library.html
  • RedBook: WebSphere V5 Performance, Scalability, and High Availability: www.redbooks.ibm.com/abstracts/sg246198.html
  • RedPaper: Server Clusters For High Availability in WebSphere Application Server Network Deployment V5: www.ibm.com/support/docview.wss?uid=swg27002473
  • Maintain continuous availability while updating WebSphere Application Server enterprise applications: www.ibm.com/developerworks/websphere/techjournal/0412_vansickel/0412_vansickel.html
  • Using WebSphere Application Server V5 for Load balancing and Failover: www.ibm.com/developerworks/ibm/library/i-wasldbal/index.html

    A detailed list of resources pertaining to this article can be found online at http://sys-con.com/websphere/searle_resources.html.

  • More Stories By Ellen Matheson McKay

    Ellen Matheson McKay is an information developer for IBM Canada Ltd. She writes online help and publications for Rational Application Developer.

    More Stories By Barry Searle

    Barry Searle is the architect for WebSphere Tools for Automated Build and Deployment. A professional engineer, he has worked at the IBM Canada Lab for over 15 years on various application development tools. Prior to that he worked on developing command and control systems, and leading complex communications development projects.

    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
    There are lots of challenges in IoT around secure, scalable and business friendly infrastructure for enterprises. For large corporations, IoT implementations are one of the top priorities of the decade. All industries are seeing a competitive need to sustain by investing in IoT initiatives. The value addition comes from improved customer service, innovative product and additional revenue streams. The data from these IP-connected devices can be leveraged for a variety of business applications as well as responsive action controls. The various architectural building blocks of an IoT ...
    Chuck Piluso will present a study of cloud adoption trends and the power and flexibility of IBM Power and Pureflex cloud solutions. Speaker Bio: Prior to Data Storage Corporation (DSC), Mr. Piluso founded North American Telecommunication Corporation, a facilities-based Competitive Local Exchange Carrier licensed by the Public Service Commission in 10 states, serving as the company's chairman and president from 1997 to 2000. Between 1990 and 1997, Mr. Piluso served as chairman & founder of International Telecommunications Corporation, a facilities-based international carrier licensed by t...
    “In the past year we've seen a lot of stabilization of WebRTC. You can now use it in production with a far greater degree of certainty. A lot of the real developments in the past year have been in things like the data channel, which will enable a whole new type of application," explained Peter Dunkley, Technical Director at Acision, in this SYS-CON.tv interview at @ThingsExpo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
    SYS-CON Events announced today that Ciqada 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. Ciqada™ makes it easy to connect your products to the Internet. By integrating key components - hardware, servers, dashboards, and mobile apps - into an easy-to-use, configurable system, your products can quickly and securely join the internet of things. With remote monitoring, control, and alert messaging capability, you will meet your customers' needs of tomorrow - today! Ciqada. Let your products take flight. For more inform...
    WebRTC is an up-and-coming standard that enables real-time voice and video to be directly embedded into browsers making the browser a primary user interface for communications and collaboration. WebRTC runs in a number of browsers today and is currently supported in over a billion installed browsers globally, across a range of platform OS and devices. Today, organizations that choose to deploy WebRTC applications and use a host machine that supports audio through USB or Bluetooth can use Plantronics products to connect and transit or receive the audio associated with the WebRTC session.
    The best mobile applications are augmented by dedicated servers, the Internet and Cloud services. Mobile developers should focus on one thing: writing the next socially disruptive viral app. Thanks to the cloud, they can focus on the overall solution, not the underlying plumbing. From iOS to Android and Windows, developers can leverage cloud services to create a common cross-platform backend to persist user settings, app data, broadcast notifications, run jobs, etc. This session provides a high level technical overview of many cloud services available to mobile app developers, includi...
    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
    Health care systems across the globe are under enormous strain, as facilities reach capacity and costs continue to rise. M2M and the Internet of Things have the potential to transform the industry through connected health solutions that can make care more efficient while reducing costs. In fact, Vodafone's annual M2M Barometer Report forecasts M2M applications rising to 57 percent in health care and life sciences by 2016. Lively is one of Vodafone's health care partners, whose solutions enable older adults to live independent lives while staying connected to loved ones. M2M will continue to gr...
    Dave will share his insights on how Internet of Things for Enterprises are transforming and making more productive and efficient operations and maintenance (O&M) procedures in the cleantech industry and beyond. Speaker Bio: Dave Landa is chief operating officer of Cybozu Corp (kintone US). Based in the San Francisco Bay Area, Dave has been on the forefront of the Cloud revolution driving strategic business development on the executive teams of multiple leading Software as a Services (SaaS) application providers dating back to 2004. Cybozu's kintone.com is a leading global BYOA (Build Your O...
    As enterprises move to all-IP networks and cloud-based applications, communications service providers (CSPs) – facing increased competition from over-the-top providers delivering content via the Internet and independently of CSPs – must be able to offer seamless cloud-based communication and collaboration solutions that can scale for small, midsize, and large enterprises, as well as public sector organizations, in order to keep and grow market share. The latest version of Oracle Communications Unified Communications Suite gives CSPs the capability to do just that. In addition, its integration ...
    The IoT Bootcamp is coming to Cloud Expo | @ThingsExpo on June 9-10 at the Javits Center in New York. Instructor. Registration is now available at http://iotbootcamp.sys-con.com/ Instructor Janakiram MSV previously taught the famously successful Multi-Cloud Bootcamp at Cloud Expo | @ThingsExpo in November in Santa Clara. Now he is expanding the focus to Janakiram is the founder and CTO of Get Cloud Ready Consulting, a niche Cloud Migration and Cloud Operations firm that recently got acquired by Aditi Technologies. He is a Microsoft Regional Director for Hyderabad, India, and one of the f...
    The 17th International Cloud Expo has announced that its Call for Papers is open. 17th International Cloud Expo, to be held November 3-5, 2015, at the Santa Clara Convention Center in Santa Clara, CA, brings together Cloud Computing, APM, APIs, Microservices, Security, Big Data, Internet of Things, DevOps and WebRTC to one location. With cloud computing driving a higher percentage of enterprise IT budgets every year, it becomes increasingly important to plant your flag in this fast-expanding business opportunity. Submit your speaking proposal today!
    While not quite mainstream yet, WebRTC is starting to gain ground with Carriers, Enterprises and Independent Software Vendors (ISV’s) alike. WebRTC makes it easy for developers to add audio and video communications into their applications by using Web browsers as their platform. But like any market, every customer engagement has unique requirements, as well as constraints. And of course, one size does not fit all. In her session at WebRTC Summit, Dr. Natasha Tamaskar, Vice President, Head of Cloud and Mobile Strategy at GENBAND, will explore what is needed to take a real time communications ...
    How is unified communications transforming the way businesses operate? In his session at WebRTC Summit, Arvind Rangarajan, Director of Product Marketing at BroadSoft, will discuss how to extend unified communications experience outside the enterprise through WebRTC. He will also review use cases across different industry verticals. Arvind Rangarajan is Director, Product Marketing at BroadSoft. He has over 19 years of experience in the telecommunications industry in various roles such as Software Development, Product Management and Product Marketing, applied across Wireless, Unified Communic...
    SYS-CON Events announced today that MangoApps 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. MangoApps provides private all-in-one social intranets allowing workers to securely collaborate from anywhere in the world and from any device. Social, mobile, and easy to use. MangoApps has been named a "Market Leader" by Ovum Research and a "Cool Vendor" by Gartner...
    SYS-CON Media announced today that @ThingsExpo Blog launched with 7,788 original stories. @ThingsExpo 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. @ThingsExpo Blog can be bookmarked. The Internet of Things (IoT) is the most profound change in personal and enterprise IT since the creation of the Worldwide Web more than 20 years ago.
    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
    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.
    Containers and microservices have become topics of intense interest throughout the cloud developer and enterprise IT communities. Accordingly, attendees at the upcoming 16th Cloud Expo at the Javits Center in New York June 9-11 will find fresh new content in a new track called PaaS | Containers & Microservices Containers are not being considered for the first time by the cloud community, but a current era of re-consideration has pushed them to the top of the cloud agenda. With the launch of Docker's initial release in March of 2013, interest was revved up several notches. Then late last...
    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...