Click here to close now.




















Welcome!

IBM Cloud Authors: Pat Romanski, Kevin Benedict, Elizabeth White, Carmen Gonzalez, XebiaLabs Blog

Related Topics: IBM Cloud

IBM Cloud: Article

How To Deploy Scalable WebSphere Applications Using "Maven" Build Tool

Scalability means how well an application performs with an ever-increasing load

When people talk about scalability, they are usually referring to how well an application performs with an ever-increasing load. Another type of scalability that needs attention during an application's life cycle is build scalability, or how well an application's build and deployment scales with ever-increasing complexity and components.

Maven is a build tool from Apache that addresses build scalability. Maven uses simple project descriptors and a highly extensible and open architecture to build, deploy, and release application components.

Through project descriptors, new components can be added to an application's build with little effort from a developer. Once added, Maven determines the component's placement in the application build order through its dependencies, and builds, deploys, and releases the new component and application bundle accordingly.

This article is not intended to be an extensive guide to using Maven and it assumes the reader has a working knowledge of Maven. For more in depth information about Maven's capabilities, visit http://maven.apache.org. Also, a good introduction to Maven's project descriptors and building a generic J2EE application with Maven is found in Charles Chan's article "Project Management: Maven Makes it Easy."

Benefits of Using Maven for WAS Deployment

With the tight integration between WebSphere Application Server (WAS) and WebSphere Studio Application Developer (WSAD), you may question the need to use an external tool to build and deploy J2EE applications to WebSphere. WSAD is a powerful, full-service tool that is capable of building J2EE applications and deploying them on WAS. However, there are some reasons for using Maven to supplement the building and deployment services provided by WSAD:

  • Maven makes build independent of a developer's IDE. Developers are creatures of habit and prefer to work with the coding environment in which they are most comfortable and most productive. By using Maven to build and deploy applications, developers are free to use any IDE they choose, which should result in more efficient developers.
  • Maven can easily be incorporated into a continuous integration environment. The frequent running of unit and integration tests and timely feedback afforded by continuous integration is crucial for team development. Maven builds are already supported by many continuous integration tools, including CruiseControl and Anthill.
  • Maven runs on any environment with a J2SE SDK. Sometimes the target environment hosting WAS is not supported by a developer's chosen IDE. Even with the "write once, run everywhere" promise of Java, portability problems arise when Java applications are written on one environment and installed on another. Since Maven can run on every environment supported by WAS, J2EE applications can be built, tested, and deployed on the same environment hosting WAS, mitigating the chance portability issues go undetected.
  • Maven can handle the most complex of build scenarios. As applications and systems become more complex and integrations between disparate enterprise resources become commonplace, it is essential that an application's build can be maintained easily and efficiently. Through a series of plug-ins, Maven is capable of interfacing with many commonly used, development resources. These plug-ins include support for testing through JUnit, source generation using XDoclet, static analysis via JDepend, interaction with Web servers such as Tomcat, plus many more. In addition to the existing Maven plug-ins, if an application's build needs to interface with a resource unsupported by Maven, plug-ins can easily be created using scripting, Java programming, or a combination of the two.

Installing the Needed Software

To illustrate how Maven can be utilized to deploy to WAS, a simple J2EE application will be deployed. The application will be bundled and deployed as an EAR and will consist of a utility JAR, an EJB JAR, and a WAR. For the purposes of this exercise, the development and deployment environment will consist of:

  • WebSphere Application Server 5.1
  • IBM JDK 1.4.1 (included with WAS install)
  • Maven 1.0
  • WebSphere 5.0/5.1 Plug-in 1.2

INSTALLING WAS
It is assumed that WAS is installed and working correctly. If WAS is not installed, run the WAS install wizard choosing the full installation.

Once WAS is installed, set the JAVA_HOME environment variable to $WAS_HOME/java, where WAS_HOME is the root directory of the WAS installation. This setting is required. The subsequent WAS deployment only works using IBM's JDK.

INSTALLING MAVEN
To install Maven, it's best to follow the Installing Maven instructions.

Once Maven is installed, create or edit the $HOME/build.properties file, where HOME is the user's home directory. In this file, add the following line:

maven.was5.home = $WAS_HOME

again, where WAS_HOME is the root directory of the WAS installation.

Of note, an Internet connection is required by Maven in order to download any needed dependency JARs. If the connection is through a proxy, additional proxy settings must be added to the $HOME/build.properties files.

INSTALLING WEBSPHERE PLUG-IN
The WebSphere 5.0/5.1 plug-in is available from the Maven Plug-ins project. Using this plug-in makes deploying J2EE applications to WAS extremely easy and provides a highly reusable approach to deploying many applications efficiently. To install the plug-in, use Maven itself. Simply enter the following command on a single line at a command prompt:

> maven plugin:download
-Dmaven.repo.remote=http://maven-plugins.sourceforge.net/maven/
-DgroupId=maven-plugins
-DartifactId=maven-was5-plugin
-Dversion=1.2

INSTALLING THE SAMPLE J2EE APPLICATION
The entire application is contained in the archive. To install the application, simply unarchive the files into any directory. This directory will be referred to as ROOT in the remainder of this article.

The Sample Application

PROJECT LAYOUT
In the situation of a multicomponent project, such as this J2EE application, it is easiest to divide the project into many modules with each one responsible for building a single component. Then have a top-level project controlling the building of the modules.

Each of the modules, as well as the top-level project, is a Maven project. Each of these Maven projects has the same general setup:

  • A required Maven project descriptor (a project.xml file) that defines project dependencies, source files, and other metadata
  • An optional Maven build script (a maven.xml file) that customizes the build for a project
  • Optional project-specific properties (a project.properties file) used to customize the build setting for a project.

UTILITY JAR MODULE
The sample-util module (located at ROOT/modules/sample-util) creates a simple, utility JAR that might be shared across many application components. Setting up the sample-util JAR module is straightforward and involves defining the build information in the project descriptor as well as defining the target goal in the Maven build script.

Of note in the project descriptor is the sourceDirectory element. It defines the directory (relative to the sample-util directory) containing all the Java source files to be compiled into class files. These class files will be bundled into the sample-util JAR.

The Maven build script is as simple as it can get. It contains a single build goal, which is also defined as the default goal:

<!-- Install jar into local repository -->
<goal name="build" prereqs="jar:install"/>

The jar:install goal is the prerequisite goal because it is necessary for the JAR to be in Maven's local repository in order to build other subprojects depending on sample-util.

EJB JAR MODULE
The sample-ejb module (located at ROOT/modules/sample-ejb) creates an EJB JAR replete with all Java classes, deployed code, and EJB bindings needed for WAS deployment. Setting up this EJB JAR involves using a combination of out-of-the-box Maven plug-ins and customizing the build for WAS-specific details.

The build information found in this module's project descriptor is similar to that found in the sample-util project. The only change is the addition of dependencies. The most important dependency is the sample-util entry:

 


<dependency>
  <groupId>maven-was</groupId>
  <artifactId>sample-util</artifactId>
  <version>1.0</version>
  <properties>
    <ejb.manifest.classpath>true</ejb.manifest.classpath>
  </properties>
</dependency>

This dependency is crucial for a few reasons. First, it allows this project's source files to be compiled because all dependency JAR files are added to the compilation classpath. Second, it assures that Maven always builds the sample-util module before building the sample-ejb module. Last, the ejb.manifest.classpath element informs Maven to add the sample-util JAR to the classpath found in the EJB JAR's manifest, which is created by Maven.

The build script for this project is more involved than that found in the sample-util project. This is the result of the additional WAS-specific tasks that need to be completed in order to create an EJB JAR deployable on WAS.

Like the sample-util project, this project contains a build goal:

<!-- Install jar into local repository -->
<goal name="build" prereqs="ejb:install"/>

The ejb:install prerequisite goal is used to install the EJB JAR into the local repository so it too is available for building subsequent subprojects.

Prior to installing the EJB JAR to the local repository, WAS-specific deployed code must be added to the EJB JAR. This can be accomplished by attaining the was5:ejbDeploy goal provided by the WebSphere plug-in. To hook into Maven's build process, a custom post goal is defined:

 


<!-- generate deployment and rmic code for an ejb jar -->
<postGoal name="ejb:ejb">
  <attainGoal name="was5:ejbDeploy"/>
 
  <!-- copy jar with deployed code over original -->
  <copy file="${maven.was5.ejbDeploy.file.out}"
        tofile="${maven.build.dir}/${maven.final.name}.jar"/>
</postGoal>

This post goal is defined to run after the ejb:ejb goal, which creates the raw EJB JAR, is complete. The post goal in turn attains the was5:ejbDeploy goal and then copies the EJB JAR with deployed code over the original, raw EJB JAR.

Another aspect of creating WAS deployable EJB JARs is ensuring the EJB deployment descriptor and WAS EJB bindings are bundled with the EJB JAR. Bundling resource files inside an EJB JAR is accomplished by placing them in the src/ejb directory of this module. The src/ejb directory is significant as it is the default setting for the maven.ejb.src property. This property defines the root directory containing files to be included in the EJB JAR. When the resource files found in this directory are copied into the EJB JAR, the directory structure is preserved. Therefore, by placing both the ejb-jar.xml and ibm-ejb-jar-bnd.xmi files in the src/ejb/META-INF directory, these files are easily bundled in the EJB JAR in their correct location.

WAR MODULE
The sample-war module (located at ROOT/modules/sample-war) creates a WAR containing JSPs, servlets, and other WAR resources. Setting up the WAR module is, again, straightforward and involves correctly defining dependencies in the project descriptor as well as customizing the build script.

The build information found in this module's project descriptor is similar to that found in the sample-util module. Again, some dependencies are added to ensure correct compilation and bundling:

 


<dependency>
  <groupId>maven-was</groupId>
  <artifactId>sample-ejb</artifactId>
  <version>1.0</version>
  <type>ejb</type>
</dependency>
<dependency>
  <id>commons-codec</id>
  <version>1.3</version>
  <properties>
    <war.bundle>true</war.bundle>
  </properties>
</dependency>

By adding the sample-ejb dependency, Maven always builds the sample-ejb module before building the sample-war module. Also, note the war.bundle element for the commons-codec dependency. This informs Maven to bundle the commons-codec JAR in the WEB-INF/lib directory of the final WAR.

Again, the build script is very simple, like that for the sample-util module. It contains the single build goal with the single prerequisite goal. This time the prerequisite is war:install:

<!-- Install war into local repository -->
<goal name="build" prereqs="war:install"/>

The war:install prerequisite is called to install the WAR into the local repository so it too is available for building subsequent modules.

As for the WAR resources, they are automatically bundled into the final WAR provided they reside in the src/webapp directory of this module. This src/webapp directory is special as it is the default setting for the maven.war.src property. This property defines the root directory housing the files to be included in the WAR. So, to include JSPs, images, deployment descriptors, and the like, simply place those resources in that directory.

EAR MODULE
The final module is the sample-ear module (located at ROOT/modules/sample-ear). This module is responsible for bundling all other modules into an EAR and deploying it to WAS. As before, this is accomplished through project dependencies and a custom build script.

In addition to the normal setup, this module requires a couple of property settings to aid with the deployment. These properties are added to the project.properties file and are as follows:

maven.ear.appxml.generate = true
maven.ear.displayname = MavenWasSample

The maven.ear.appxml.generate property informs Maven to generate the deployment descriptor for the application. The maven.ear.displayname property sets the application's display name. This change in name is needed because the default display name contains illegal characters and is an invalid WAS application name.

This module's project descriptor lists all the other modules as dependencies to ensure correct compilation and bundling (see Listing 1).

By adding the other module dependencies, Maven always builds the other projects before building the sample-ear module. Also, note the ear.bundle and ear.appxml.war.context-root elements for the dependencies. The ear.bundle element informs Maven to bundle each dependency's final artifact in the EAR. The ear.appxml.war.context-root is unique to WAR dependencies and specifies which context root to use for the Web application. This value is added to the EAR deployment descriptor that is generated by Maven.

Like the sample-ejb module, the build script for this module involves some WAS-specific tasks used to actually deploy and start the J2EE application.

Again, like the other modules, this module contains a build goal:

<!-- Install ear into local repository -->
<goal name="build" prereqs="ear:install"/>

Prior to installing the EAR to the local repository, the WAS-specific goals can be invoked to actually deploy the EAR. This is accomplished via a post goal set to run after the ear:ear goal, which creates the EAR, is completed. This post goal in turn attains the WAS goals to actually perform the application deployment (see Listing 2).

The post goal provides the means to either deploy the EAR (using the was5:installApp and was5:startApp goals) or reinstall the EAR (using the was5:reinstallApp) over an existing deployment. How that choice is determined will be illustrated shortly in the Rebuild the Application section.

TOP-LEVEL PROJECT
The top-level project (located at ROOT) is responsible for building all the modules and acts as a controller over the entire build process.

The project descriptor is quite simple and contains only rudimentary metadata about the project. It is simple because the top-level project contains no source code so all the build information is omitted.

The build script is also very simple, yet very crucial to building the entire application. The default goal of the build script is build. This goal uses the Maven reactor plug-in to propagate the build goal to all of the modules contained in the application. The reactor is responsible for determining the module build order based on their individual dependencies and is responsible for attaining the build goal for each of the modules. The relevant goals are shown in Listing 3.

Deploying the J2EE Application

BUILD THE APPLICATION
With all the project descriptors and build scripts in place for the module, building and deploying the EAR is a simple exercise:

  1. Ensure the WAS server is running.
  2. Execute Maven from ROOT:

    > maven

  3. Sit back and witness the magic.

What is actually witnessed from the command line are the steps Maven takes to build and deploy the application.

First, the Maven reactor determines the build order of the modules based on their interdependencies. This is indicated by the following output:

Starting the reactor...
Our processing order:
sample-util
sample-ejb
sample-war
sample-ear

Next, the first module, sample-util, is built. This is indicated by the following output:

+----------------------------------------
| Executing (build): sample-util
| Memory: 9M/10M
+----------------------------------------

The subsequent output details all the goals attained in order to create the sample-util JAR. These goals include:

  • java:compile: compiles all the source files
  • test:test: runs any JUnit tests
  • jar:jar: actually bundles everything into the final sample-util JAR

After sample-util is built, sample-ejb is built as illustrated by the output:

+----------------------------------------
| Executing (build): sample-ejb
| Memory: 10M/19M
+----------------------------------------

The proceeding output details the step taken to create the sample-ejb EJB JAR. These steps for the most part mirror those taken to build the sample-util JAR.

Of special note are the many lines of output involving the was5:ejbDeploy goal whose successful completion is indicated by:

[wasEjbDeploy] EJBDeploy complete.
[wasEjbDeploy] 0 Errors, 0 Warnings, 0 Informational Messages

Next, sample-war is built, which is indicated by the output:

+----------------------------------------
| Executing (build): sample-war
| Memory: 17M/19M
+----------------------------------------

Again, a series of goal output follows detailing the steps required to build the WAR.

Finally, sample-ear is built starting with the output:

+----------------------------------------
| Executing (build): sample-ear
| Memory: 17M/19M
+----------------------------------------

Of special note in the subsequent output are the many lines of output involving the was5:installApp and was:startApp goals whose successful completion are respectfully indicated by:

[wasInstallApp] ADMA5013I: Application MavenWasSample installed successfully.

and

[wasStartApp] Started Application [MavenWasSample]

VERIFY THE DEPLOYMENT
After Maven is finished deploying the EAR, the application can be tested to ensure the EAR was successfully deployed. The Web application contains a simple JSP page accessible at http://localhost:9080/sample/digest.jsp. If the EAR is working properly, the page should display a simple form that can be used to perform MD5 hashing of entered text.

REBUILD THE APPLICATION
Once the application is working correctly, it may become necessary to reinstall the application if it is ever modified. This can also be accomplished through Maven by adding a property to the command line:

> maven -Dwas.reinstall.app=true

Customize the Deployment

Throughout the article a WAS default installation on a local machine was assumed. To deploy the application to a WAS instance with a special configuration, the build needs to be modified to accommodate those unique environments. Luckily, the WebSphere plug-in provides many configurable properties that can be set to alter the deployment behavior. Some of the most commonly used properties are shown in Table 1.

To use the SE properties, simply specify new property values on the command line. For example, to deploy the application to a different server needing user authentication, use a command like the following:

> maven -Dmaven.was5.server=myserver -Dmaven.was5.username=deployer
-Dmaven.was5.password=pw4deployer

The plug-in offers a wider range of configuration properties than those listed above and used in this article. Be sure to visit the WebSphere plug-in Web site to learn all of the plug-in's options

Promise of Build Scalability

In the beginning of this article, it was stated that Maven could help address build scalability by making it easy to add and maintain new components to a J2EE application.

How easy is it to add another EJB JAR or WAR to this application? To add another utility JAR, EJB JAR, or WAR to the application, all that needs to be done is to replicate the subproject structure for the type of component to be added, modify the project descriptor with the new project metadata and dependencies, and finally add the new component to the EAR's list of dependencies. After that is complete, when Maven is used next to deploy the EAR, the new component will be built with all the other modules and it will be bundled in the final J2EE application.

Summary

The ease of building and deploying J2EE applications and its ability to interface with an ever-increasing number of development tools and resources make Maven a viable build solution for WAS deployment.

Comments (17) View Comments

Share your thoughts on this story.

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

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


Most Recent Comments
Ronald 08/10/06 07:05:13 AM EDT

Hi, Very interesting article, but can You sent to me the sample J2EE application.

Tim 04/12/06 04:10:18 AM EDT

HI, Brend! Your article really helps to understand Maven integration with WP. It will be nice if you attach or send me via email sample project used by this article (:"The entire application is contained in the archive.").
Thank you.

Pin Koh 12/22/05 11:52:17 AM EST

How does one make use of maven with websphere and be able to allow developer to still be able to use WSAD to write code? My concerns are about .project, .classpath, ibm-web-bnd.xmi...etc. How do we deal with these propriatory configuration. Are there plug-ins that can generate these?

Khurram 12/02/05 12:49:03 PM EST

please post the source code, as this seems to be a useful article

SYS-CON Italy News Desk 11/10/05 02:24:07 PM EST

How To Deploy Scalable WebSphere Applications Using "Maven" Build Tool. When people talk about scalability, they are usually referring to how well an application performs with an ever-increasing load. Another type of scalability that needs attention during an application's life cycle is build scalability, or how well an application's build and deployment scales with ever-increasing complexity and components.

JDJ News Desk 11/10/05 02:04:29 PM EST

How To Deploy Scalable WebSphere Applications Using "Maven" Build Tool. When people talk about scalability, they are usually referring to how well an application performs with an ever-increasing load. Another type of scalability that needs attention during an application's life cycle is build scalability, or how well an application's build and deployment scales with ever-increasing complexity and components.

WebSphere News Desk 11/10/05 01:32:50 PM EST

When people talk about scalability, they are usually referring to how well an application performs with an ever-increasing load. Another type of scalability that needs attention during an application's life cycle is build scalability, or how well an application's build and deployment scales with ever-increasing complexity and components.

Enterprise Open Source Magazine News Desk 11/10/05 01:18:56 PM EST

How To Deploy Scalable WebSphere Applications Using "Maven" Build Tool. When people talk about scalability, they are usually referring to how well an application performs with an ever-increasing load. Another type of scalability that needs attention during an application's life cycle is build scalability, or how well an application's build and deployment scales with ever-increasing complexity and components.

WebSphere News Desk 11/10/05 12:44:47 PM EST

How To Deploy Scalable WebSphere Applications Using "Maven" Build Tool. When people talk about scalability, they are usually referring to how well an application performs with an ever-increasing load. Another type of scalability that needs attention during an application's life cycle is build scalability, or how well an application's build and deployment scales with ever-increasing complexity and components.

Sam Brodkin 11/10/05 12:19:12 PM EST

I made an example app using the was5 xdoclet plugin along with spring and maven that may help some people out:

http://www.jroller.com/page/brodkin?entry=the_spring_framework_rules

Chuck Lamprey 06/08/05 01:08:46 PM EDT

I have to agree with the other readers: the article appears to be good, but since there is no source code available other than the XML Maven-related files, it is almost impossible to assess. I'm dissappointed that the WebSphere Journal would publish an article like this without ensuring availability of the full source.

To the Duty Editor who stated that the source code exists at the "Source Code" link: the only files that exist are a few XML files. The directory structure, the Java files and any WebSphere specific config files are not contained in the link.

forumer 05/11/05 01:06:31 PM EDT

Where can I find this sample websphere application in the archive you talked about? It will be very helpful to go through the exercise with that sample application.

Jim 03/03/05 02:30:37 PM EST

This article of no use, unless actual source code is plublished.

Robert Fletcher 12/28/04 09:50:14 PM EST

Could you please post a zip file that has the COMPLETE maven scripts as well as the source for the application. Otherwise this article is not very usefull.

Also, Since most Websphere developers use WSAD, It would be MORE useful to present an article in which the SOURCE code directory matches a WSAD workspace.

thanx

Brian 12/10/04 02:54:15 PM EST

I see the listings but would it be possible to post the source?

Duty Editor 12/03/04 03:37:28 PM EST

Sujan, re Listings

They're at the end of the article, under
sourcecode

Sujan Deb 12/03/04 12:54:48 PM EST

Hi Brent,

Overall the article was very informative. As there are very few articles available related to was and maven integration, I found this one very useful. In few of the places you have specified "Table 1" and "Listing 1" but we could not find them. Moreover, it will be great if you could host the sample code that you have used in your artile.

Thanks in advance
Sujan Deb
1-416-861-5242
sujan.deb@cibc.com

@ThingsExpo Stories
Contrary to mainstream media attention, the multiple possibilities of how consumer IoT will transform our everyday lives aren’t the only angle of this headline-gaining trend. There’s a huge opportunity for “industrial IoT” and “Smart Cities” to impact the world in the same capacity – especially during critical situations. For example, a community water dam that needs to release water can leverage embedded critical communications logic to alert the appropriate individuals, on the right device, as soon as they are needed to take action.
A producer of the first smartphones and tablets, presenter Lee M. Williams will talk about how he is now applying his experience in mobile technology to the design and development of the next generation of Environmental and Sustainability Services at ETwater. In his session at @ThingsExpo, Lee Williams, COO of ETwater, will talk about how he is now applying his experience in mobile technology to the design and development of the next generation of Environmental and Sustainability Services at ETwater.
SYS-CON Events announced today that IceWarp will exhibit at the 17th International Cloud Expo®, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. IceWarp, the leader of cloud and on-premise messaging, delivers secured email, chat, documents, conferencing and collaboration to today's mobile workforce, all in one unified interface
WebRTC has had a real tough three or four years, and so have those working with it. Only a few short years ago, the development world were excited about WebRTC and proclaiming how awesome it was. You might have played with the technology a couple of years ago, only to find the extra infrastructure requirements were painful to implement and poorly documented. This probably left a bitter taste in your mouth, especially when things went wrong.
Too often with compelling new technologies market participants become overly enamored with that attractiveness of the technology and neglect underlying business drivers. This tendency, what some call the “newest shiny object syndrome,” is understandable given that virtually all of us are heavily engaged in technology. But it is also mistaken. Without concrete business cases driving its deployment, IoT, like many other technologies before it, will fade into obscurity.
While many app developers are comfortable building apps for the smartphone, there is a whole new world out there. In his session at @ThingsExpo, Narayan Sainaney, Co-founder and CTO of Mojio, will discuss how the business case for connected car apps is growing and, with open platform companies having already done the heavy lifting, there really is no barrier to entry.
As more intelligent IoT applications shift into gear, they’re merging into the ever-increasing traffic flow of the Internet. It won’t be long before we experience bottlenecks, as IoT traffic peaks during rush hours. Organizations that are unprepared will find themselves by the side of the road unable to cross back into the fast lane. As billions of new devices begin to communicate and exchange data – will your infrastructure be scalable enough to handle this new interconnected world?
SYS-CON Events announced today that Micron Technology, Inc., a global leader in advanced semiconductor systems, will exhibit at the 17th International Cloud Expo®, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. Micron’s broad portfolio of high-performance memory technologies – including DRAM, NAND and NOR Flash – is the basis for solid state drives, modules, multichip packages and other system solutions. Backed by more than 35 years of technology leadership, Micron's memory solutions enable the world's most innovative computing, consumer,...
SYS-CON Events announced today that Pythian, a global IT services company specializing in helping companies leverage disruptive technologies to optimize revenue-generating systems, has been named “Bronze Sponsor” of SYS-CON's 17th Cloud Expo, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. Founded in 1997, Pythian is a global IT services company that helps companies compete by adopting disruptive technologies such as cloud, Big Data, advanced analytics, and DevOps to advance innovation and increase agility. Specializing in designing, imple...
SYS-CON Events announced today that HPM Networks will exhibit at the 17th International Cloud Expo®, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. For 20 years, HPM Networks has been integrating technology solutions that solve complex business challenges. HPM Networks has designed solutions for both SMB and enterprise customers throughout the San Francisco Bay Area.
Consumer IoT applications provide data about the user that just doesn’t exist in traditional PC or mobile web applications. This rich data, or “context,” enables the highly personalized consumer experiences that characterize many consumer IoT apps. This same data is also providing brands with unprecedented insight into how their connected products are being used, while, at the same time, powering highly targeted engagement and marketing opportunities. In his session at @ThingsExpo, Nathan Treloar, President and COO of Bebaio, will explore examples of brands transforming their businesses by t...
Through WebRTC, audio and video communications are being embedded more easily than ever into applications, helping carriers, enterprises and independent software vendors deliver greater functionality to their end users. With today’s business world increasingly focused on outcomes, users’ growing calls for ease of use, and businesses craving smarter, tighter integration, what’s the next step in delivering a richer, more immersive experience? That richer, more fully integrated experience comes about through a Communications Platform as a Service which allows for messaging, screen sharing, video...
With the proliferation of connected devices underpinning new Internet of Things systems, Brandon Schulz, Director of Luxoft IoT – Retail, will be looking at the transformation of the retail customer experience in brick and mortar stores in his session at @ThingsExpo. Questions he will address include: Will beacons drop to the wayside like QR codes, or be a proximity-based profit driver? How will the customer experience change in stores of all types when everything can be instrumented and analyzed? As an area of investment, how might a retail company move towards an innovation methodolo...
The Internet of Things (IoT) is about the digitization of physical assets including sensors, devices, machines, gateways, and the network. It creates possibilities for significant value creation and new revenue generating business models via data democratization and ubiquitous analytics across IoT networks. The explosion of data in all forms in IoT requires a more robust and broader lens in order to enable smarter timely actions and better outcomes. Business operations become the key driver of IoT applications and projects. Business operations, IT, and data scientists need advanced analytics t...
As more and more data is generated from a variety of connected devices, the need to get insights from this data and predict future behavior and trends is increasingly essential for businesses. Real-time stream processing is needed in a variety of different industries such as Manufacturing, Oil and Gas, Automobile, Finance, Online Retail, Smart Grids, and Healthcare. Azure Stream Analytics is a fully managed distributed stream computation service that provides low latency, scalable processing of streaming data in the cloud with an enterprise grade SLA. It features built-in integration with Azur...
Akana has announced the availability of the new Akana Healthcare Solution. The API-driven solution helps healthcare organizations accelerate their transition to being secure, digitally interoperable businesses. It leverages the Health Level Seven International Fast Healthcare Interoperability Resources (HL7 FHIR) standard to enable broader business use of medical data. Akana developed the Healthcare Solution in response to healthcare businesses that want to increase electronic, multi-device access to health records while reducing operating costs and complying with government regulations.
For IoT to grow as quickly as analyst firms’ project, a lot is going to fall on developers to quickly bring applications to market. But the lack of a standard development platform threatens to slow growth and make application development more time consuming and costly, much like we’ve seen in the mobile space. In his session at @ThingsExpo, Mike Weiner, Product Manager of the Omega DevCloud with KORE Telematics Inc., discussed the evolving requirements for developers as IoT matures and conducted a live demonstration of how quickly application development can happen when the need to comply wit...
The Internet of Everything (IoE) brings together people, process, data and things to make networked connections more relevant and valuable than ever before – transforming information into knowledge and knowledge into wisdom. IoE creates new capabilities, richer experiences, and unprecedented opportunities to improve business and government operations, decision making and mission support capabilities.
Explosive growth in connected devices. Enormous amounts of data for collection and analysis. Critical use of data for split-second decision making and actionable information. All three are factors in making the Internet of Things a reality. Yet, any one factor would have an IT organization pondering its infrastructure strategy. How should your organization enhance its IT framework to enable an Internet of Things implementation? In his session at @ThingsExpo, James Kirkland, Red Hat's Chief Architect for the Internet of Things and Intelligent Systems, described how to revolutionize your archit...
MuleSoft has announced the findings of its 2015 Connectivity Benchmark Report on the adoption and business impact of APIs. The findings suggest traditional businesses are quickly evolving into "composable enterprises" built out of hundreds of connected software services, applications and devices. Most are embracing the Internet of Things (IoT) and microservices technologies like Docker. A majority are integrating wearables, like smart watches, and more than half plan to generate revenue with APIs within the next year.