Click here to close now.


Java IoT Authors: AppDynamics Blog, Brad Thies, Flint Brenton, Liz McMillan, Deep Bhattacharjee

Related Topics: Java IoT

Java IoT: Article

JSP 2.0 Technology

JSP 2.0 Technology

JavaServer Pages (JSP) technology originated more than four years ago as a powerful way to dynamically generate HTML on the server side. Over time, and with the input of the developer community, JSP technology has evolved and matured, keeping simplicity at the forefront. The next generation of JSP technology, version 2.0, will be released with J2EE 1.4 and represents an easy-to-use, robust, and extensible technology for building Web applications, well suited toward generating dynamic Web content in such formats as HTML, DHTML, XHTML, SVG, and XML.

The JSP 2.0 specification introduces many new features, including a simple yet flexible integrated expression language, an encapsulation mechanism called tag files, a simplified tag extension API, and a substantially improved XML syntax. Let's explore some of these features and see what they mean for your Web project.

The Evolution of JSP Technology
In its early stages, the focus of JSP technology was to enable the generation of dynamic content by embedding scriptlets (pieces of Java programming language code) within HTML template data. Programming with scriptlets can be quite flexible and powerful at times and is suitable for some types of projects. For many projects, however, such as those that follow a Model/2 or MVC (Model-View-Controller) architecture, embedding scriptlets in the presentation layer can have several disadvantages, including:
1.  The Web designers on your project need to learn the Java programming language, which has a fairly steep learning curve in comparison to, say, the JavaScript programming language. Furthermore, pages created with JSP technology ("JSP pages") with scattered pieces of code can become difficult to read and maintain.
2.  It becomes too easy to mix business logic with presentation logic, especially when working under a deadline. Even well-intentioned developers working on well-designed Web applications may find it tempting to introduce business logic in the presentation layer.
3.  Code becomes more difficult to reuse. Scriptlets frequently lead to copying and pasting of code. Tag extensions are often used to encapsulate and reuse such code. However, until this release of the specification, writing tag extensions has been a tedious and time-consuming process.

JSP technology has evolved in various ways that help make writing pages without inline scriptlets much more of a reality. These evolutions have come in the form of both changes to the specification and add-on technologies. The introduction of tag libraries in version 1.1 of the JSP specification allowed for JSP technology to be extended, and MVC frameworks like Struts began to evolve, providing a simple way to abstract business logic from the presentation layer. After improvements to tag library support in version 1.2 of the JSP specification, the JSP Standard Tag Library (JSTL) was introduced, providing a core set of useful actions such as iteration, internationalization, formatting, SQL database access, and XML manipulation. JSTL also introduced an expression language that's much easier to read and write than scriptlets. Over time, these incremental changes have helped JSP technology become quite suitable for architectures in which it is used purely as a presentation layer, while maintaining strong support for other architectures as well.

The latest JSP specification is currently in the Proposed Final Draft stage and it's under development in the Java Community Process (JCP) as Java Specification Request (JSR) 152. In combination with JSTL, the features introduced in the JSP 2.0 specification yield a cleaner, easier-to-use, and higher-performing language. In fact, page authors using JSP 2.0 technology no longer need to know or use the Java programming language, which in and of itself dramatically decreases their training requirements. Furthermore, the introduction of features like tag files and simple tag extensions enable new reuse patterns and make life easier for tag library developers.

JSP 2.0 technology is expected to have a substantial impact on the way page authors can write JSP pages. Because of this, the expert group decided to upgrade the major version number of the specification. Among other benefits, upgrading the major version number helps differentiate between developing using JSP 1.x technology (with scriptlets) and developing using JSP 2.x technology (with simple expressions and JSTL). It's important to note that though major version number upgrades often connote a break in backward compatibility, this is not the case here. Version 2.0 of the JSP specification is fully backward compatible with version 1.2.

Simple Expression Language
The JSTL 1.0 specification included a simple expression language, intended to help reduce the amount of scriptlets in a page, and to make it much easier for a page author to access application data from within a JSP page. JSTL's expression language was originally called SPEL (Simplest Possible Expression Language), and is intentionally very similar in syntax to ECMAScript (JavaScript) and XPath. By popular demand from the community, this simple expression language is now built into the JSP 2.0 specification.

To understand the motivation for the expression language, let's look at a simple example. Suppose you're a page author writing a JSP page that outputs census data for a given state. The part of your JSP page that outputs the result might look like:

The population of <%= state.getFullName() %> in 2000 was
StateInfo info = (StateInfo)stateInfo.get( state.getId() );
if( info != null ) {
<%= info.getPopulation(); %>

Writing even a fairly simple example like this requires some knowledge about the Java programming language syntax, types, variable declarations, and the danger of dereferencing a null pointer. This can be intimidating and easy to get wrong for a page author with a limited knowledge of the Java programming language.

Using the simple expression language available in the JSP 2.0 specification, the same presentation logic can be written much more concisely:

The population of ${state.fullName} in 2000 was

Here's how it works. The expression ${state.fullName} looks up the state attribute, treats it as a JavaBeans component, and calls the accessor for the fullName property (i.e., getFullName()). The expression ${stateInfo[].population} looks up the stateInfo attribute, which in this case happens to be a HashMap; finds the entry with the key that matches the value of state.getId(); and then calls getPopulation() on the resulting entry. Incidentally, the EL behaves in similar ways for maps, lists, and arrays, so there's some degree of transparency in terms of how stateInfo is actually implemented. Another nice feature of the JSTL expression language is if a null value is encountered at any point, the expression language will handle it gracefully and output nothing rather than throwing a NullPointerException that would have produced an error page instead. Of course, the page author doesn't need to know what happens behind the scenes.

Clearly, the resulting code is more readable and easier to maintain.

Using the JSP 1.2 and JSTL 1.0 technologies, the page author could use these simple expressions only inside the attributes of JSTL actions. JSP 2.0 technology allows page authors to finally use these expressions (now termed "EL expressions") directly within template text, and when passing attribute values to standard actions and tag handlers created with JSP technology ("JSP tag handlers"). That means they can be used with any tag library, even your own, with no extra work required by the tag library developer.

With the power of an integrated expression language, and with the core JSTL actions at hand, a new programming methodology is now available to JSP page authors, making scriptlets a thing of the past and dramatically reducing the learning curve associated with JSP technology. In fact, to help project leads enforce a no-scriptlets policy project-wide or in a specific set of pages, the JSP 2.0 specification now includes a global configuration mechanism to disallow scriptlets for a set of JSP pages in a Web application (among other global configuration options not discussed in this article). This was a popular feature request from project leads who were struggling to prevent developers from mixing business logic with presentation logic, especially under time pressure. Listing 1 illustrates a deployment descriptor configured to disable the use of scriptlets for all JSP pages in the /client subdirectory of the Web application. Of course, for some projects scriptlets will still make sense, and the JSP 2.0 specification supports those types of projects as well.

Writing a New EL Function
Along with a fairly complete set of operators, the expression language in the JSP 2.0 specification has built-in capabilities to access data from maps, lists, arrays of objects, and bean properties. The expression language is designed from the ground up to be intuitive to use and easy to read.

A key decision was made by the expert group to disallow unrestricted invocations on Java methods from within EL expressions. Allowing this could quickly lead to pages that mix business logic with presentation logic, leading to many of the same problems described earlier that existed with scriptlets. As always, the expert group will be observing how people use JSP 2.0 technology to see if it makes sense to loosen this restriction.

To provide a way to add to the power and flexibility of the expression language in a more controlled manner, JSP 2.0 technology adds the ability to extend the expression language through writing custom EL functions. This feature enables a developer to quickly and easily make common tasks available to the page author without having to allow unrestricted access to arbitrary method invocations.

The following code snippet shows a page that invokes an EL function that returns a random number between one and six. The function is imported as part of a tag library (tag libraries can contain both actions and functions) and the function is identified using the prefix of that tag library.

<%@ taglib prefix="my" uri="" %>

Congratulations, you rolled a ${my:randomNumber( 1, 6 )}!

Writing the implementation of the randomNumber function is quite straightforward. First, the developer writes a public static method:

/* /WEB-INF/classes/mytaglib/ */
package mytaglib;

public class Functions {
public static int randomNumberImpl( int low, int high ) {
return (int)(Math.random()

  • (high-low+1) + low);

    The static method can be in any class, and a class can implement more than one EL function.

    After the implementation is written, simply add an entry to the tag library descriptor as shown in Listing 2. Now you can use the EL function in any of your JSP pages.

    The JSTL 1.1 specification, which will be finalized at the same time as the JSP 2.0 specification, will introduce 16 standardized EL functions, covering common page author needs:

  • fn:length(): Get the length of a collection or a string.
  • fn:toUpperCase(), fn:toLowerCase(): Change the capitalization of a string.
  • fn:substring(), fn:substringBefore(), fn:substringAfter(): Get a subset of a string.
  • fn:trim(): Trim whitespace from a string.
  • fn:replace(): Replace characters in a string.
  • fn:indexOf(), fn:startsWith(), fn:endsWith(), fn:contains(), fn:containsIgnoreCase(): Check if a string contains another string.
  • fn:split(): Split a string into an array.
  • fn:join(): Join a collection into a string.
  • fn:escapeXml(): Escape XML characters in a string.

    Incidentally, the tag libraries in JSTL 1.1 have new URIs (for example, instead of the JSTL 1.0 equivalent The new JSTL 1.1 tag libraries accept request-time expressions for their attributes, and delegate to the JSP container to evaluate EL expressions. When creating a new JSP 2.0 application, you should always either (in order of preference, from highest to lowest):

  • Use JSTL 1.1
  • Use the _rt versions of the JSTL 1.0 tag libraries
  • Use the non-rt versions with isELIgnored="true" in the page directive

    Tag Files
    There are a number of ways to encapsulate reusable portions of JSP software. Since version 1.1 of the JSP specification, there have been four reuse mechanisms: the include directive, the include standard action, the forward standard action, and the custom action.

    Of the four, the custom action is the most flexible and powerful reuse mechanism and it has the most readable calling syntax. Custom actions are grouped into tag libraries, which are imported by the page author via a taglib directive. The action is then invoked by inserting a simple XML element. See Listing 3 for an example invocation of a custom action that retrieves products from the user's shopping cart and places them in the "products" variable.

    Until version 2.0 of the JSP specification, custom actions could only be implemented using the Java programming language. In version 1.2, the amount of code and configuration required to write custom actions made them typically only worthwhile for complex tasks. The JSP 2.0 specification introduces a new reuse mechanism called a tag file that allows custom actions to be written using JSP technology syntax ("JSP syntax"). This brings the power and flexibility of custom actions to page authors that don't necessarily know the Java programming language.

    In Listing 3, the <my:queryCart> custom action is used to retrieve a list of products in a shopping cart and place the list in the "products" variable. Some HTML and JSTL code is then used to render the shopping cart in a table. It would be nice to be able to reuse the presentation code that renders the table as well, so that whenever we need to display the user's cart within a JSP page, all we would have to do is type something like <my:showCart />. The cart would be queried and rendered in a single step.

    To do this, we could write our own custom action using the Java programming language, but in doing so we would run into some limitations. First, because custom actions are not designed to be invoked from within other custom actions, there would be no convenient way to reuse the existing <my:queryCart> custom action. Second, the purpose of the new <my:showCart> custom action is primarily presentation focused. The implementation would contain many out.println() statements to render the HTML. This is more difficult to read and maintain for the same reasons that servlets that mostly output HTML are more difficult to read and maintain than JSP pages that do the same.

    Tag files are the perfect solution to this situation. At its surface, a tag file is simply an easy way to write a custom action. Just as JSP pages are compiled into servlets, tag files are compiled into custom actions. Using a tag file, we can easily construct a custom action that queries the cart and renders the result. Listing 4 is an example of a tag file that does just that.

    You'll notice the code for the tag file looks almost identical to the code for the JSP page in Listing 3. One addition is the use of the attribute directive that allows us to specify that this custom action accepts an attribute with the name of "username". The value of the username attribute is then available to the tag using the EL expression ${username}.

    The beauty of tag files is that all we need to do now is save this file in /WEB-INF/tags/showCart.tag in our Web application, and we now have a new custom action. Unlike when implementing custom actions using the Java programming language, we don't need to write a tag library descriptor (TLD), and we don't need to manually compile our source code into a tag handler. Also note how easy it is to alter the presentation of the shopping cart versus what it would take to do the same if it were implemented using Java class files.

    The following code makes use of our new custom action:

    <%@ taglib prefix="tags" tagdir="/WEB-INF/tags" %>
    Here are the contents of your shopping cart:<br/>
    <tags:showCart username="${username}" />

    From the caller's perspective it's fairly transparent whether the action was implemented using a tag file or a Java class file. The only hint is the use of the tagdir attribute, which can be replaced with uri if we take the extra time to write an explicit TLD file for this tag.

    If page authors find themselves frequently copying and pasting a portion of code written in JSP or HTML syntax, perhaps with small changes each time, that portion of code can be placed in a tag file, parameterized, and then reused with minimal effort. Tag files are also a good way to move scriptlets out of your JSP pages and into a more well-defined, encapsulated place.

    Of course, not all actions are best implemented as tag files. Tags that are dominated by scriptlets or logic are probably better compiled by hand into Java class files.

    Simple Tag Extensions
    Writing a JSP 1.2 tag handler using the Java programming language requires a number of tricky steps including choosing from three possible interfaces to implement; implementing the doStartTag(), doInitBody(), doAfterBody(), and doEndTag() methods; picking return values for each method to affect the way the container evaluates the tag body and the rest of the page; and carefully checking the implementation against a complex reuse life cycle. Even some JSP technology experts have trouble getting all these steps right.

    Listing 5 shows an implementation of a JSP 1.2 tag handler that repeats the contents of its body a given number of times. Note how what should be a simple loop is spread across two separate methods and how the value of the count attribute is not allowed to be modified by the tag handler implementation so that the tag handler instance may be reused by the container.

    JSP 2.0 technology makes writing tag handlers in the Java programming language easier by providing a much simpler tag handler API. The new API is called the simple tag extension API, and JSP 1.2 tag handlers are now referred to as classic tag handlers. Figure 1 illustrates the new tag extension class hierarchy.

    When writing a simple tag handler, a tag library developer needs only to extend SimpleTagSupport and implement the doTag() method. Simple tag handlers flow more naturally and are thus easier to write, debug, read, and maintain. The one disadvantage of simple tag handlers is that scriptlets are not allowed in the bodies of these tags. Though some would consider this an advantage, it does mean that simple tag handlers cannot be used for some applications. The tag body is encapsulated in an object called a fragment, which is passed to the tag handler and invoked as many times as needed. Listing 6 shows an implementation of the same repeat action as a simple tag handler.

    Tag files are actually translated into simple tag handlers by the container and therefore have many similar properties (for example, scriptlets are not allowed in the body of a tag file invocation either). The following code shows an implementation of the repeat action using a tag file. This is actually the most convenient implementation of the three since it does not require writing a TLD or compiling any classes.

    <%-- /WEB-INF/tags/repeat.tag --%>

    <%@ taglib prefix="c" uri="" %>
    <%@ attribute name="count" rtexprvalue="true" required="true" %>

    <c:forEach begin="1" end="${count}">
    <jsp:doBody />

    We're Listening!
    This was just a quick overview of some of the more significant features new to the JSP 2.0 specification. There are many other features that were not touched on in this article, including:

  • Greatly improved XML syntax: Provides a natural fit for pages that are provided in XML syntax or that generate XML content.
  • Configuration: Allows central control over various properties of JSP pages from within the deployment descriptor.
  • Portable debugging support through JSR-45: Enables the freedom to mix and match IDEs and application servers from different vendors, for those that support this standard.
  • Dynamic attributes: Enables tag extensions to process an open-ended set of attributes.
  • Enhanced I18N support: Allows specification of page encoding on a per-file basis, among other long-awaited enhancements.
  • Fragment attributes: Effectively allows a single tag extension to accept multiple tag bodies.

    The new features in the JSP 2.0 specification, when used with other Java technologies like the JSTL tag library, bring power with simplicity to all users of JSP technology, from the basic page author who no longer needs to learn the Java programming language to the advanced tag library developer who can now write powerful tag handlers with much less overhead.

    The expert group created the new features in the JSP 2.0 specification directly from input received from the Java technology developer community at large - from people like you. Download the JSP 2.0 specification and an implementation like J2EE 1.4 SDK Beta 2 (which is based on Tomcat 5) and try these features out for yourself. Aside from support for the JSP 2.0 and Servlet 2.4 specifications, Tomcat 5 has several enhancements over Tomcat 4.0 including improved performance and a rewritten code generator that overcomes the 64K method size limitation, among other things.

    Your feedback has already made, and continues to make, a big difference!


  • J2EE 1.4 SDK Beta 2:
  • Java Web Services Developer Pack:
  • Tomcat 5:
  • Jakarta Taglibs project:
  • TLDDoc (JSP Tag Library Documentation Generator):


  • JSP 2.0 tutorial:
  • JSP 2.0 specification:
  • JSP:
  • JSTL:
  • JavaServer Faces Technology:


  • Web Applications:

    Special thanks to Eduardo Pelegri-Llopart, Pierre Delisle, Stephanie Bodoff, and Jan Luehe, whose feedback helped me improve this article.

    Java, JavaBeans, JavaScript, JSP and JCP are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries.

  • More Stories By Mark Roth

    Mark Roth is a member of the JavaTM 2 Platform, Enterprise Edition technology team. He has contributed to a number of key specifications and implementations and is currently a co-lead for the JavaServer Pages specification version 2.0. He can be contacted at [email protected]

    Comments (6) 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
    Melisa Cromwell 04/02/04 09:57:50 AM EST

    I agree 100% Thanks for having the bravery to say what many already know but are in fear of losing job if they admit true, we have tried for a year adding people, machines, training and money and have made little progress due mainly to the overwelming requirments JAVA and its other required parts forces developers to using to get even the simplest things done. Our company has finally decided to make money and go back to a productive environment, were we get apps done in months not years, I let you know in a follow up what our choice is, CFMX is on our short list. Keep up the honesty.

    Robert Wilson 09/03/03 12:17:04 PM EDT

    Why is it that when people try to use java to write web apps, they always have to add atleast 3 other technoligies or languages to get the app to work. Try PHP or Coldfusion, 1 language to learn, no add on technologies, when will java stand on its own,....Just add turbine or velocity or JSP or struts or EL or others. It obvious that to make JAVA web apps, one needs to muddy the water with many other languages, this just slows the development process. If you have lots of time people and money I guess it might work, stop spending lots of time money to make your app work. JAVA is a waste of any companys resources, The bottom line will suffer, the stock price will go down while customer wait for thier product.

    JAVA is the programming equivelent to ENRON

    jagadeesh 08/30/03 08:56:57 AM EDT

    Mark Roth,
    great stuff reg JSP 2
    M Jagadeesh

    Carfield Yim 07/11/03 02:39:00 AM EDT

    Seen like java is adding more and more language feature, except EL, there is autoboxing, generic in standard JDK.

    Is it really good?? If there is many one using old thing and new thing togather, will it make the code look like a messes?

    Rajasekhar 07/08/03 01:01:00 AM EDT

    This article is quite informative

    Valerij Timofeev 07/15/03 08:50:00 AM EDT

    The article confirms indirect that JSP < 2.0 is crap. Beginning with the version 2.0, JSP gets finally the right way. But for example with Velocity ( Java folk goes this way already for years. In the combination with Turbine ( it allows to avoid JSP at all.

    I find custom tags futile. They create only mess of HTML and freely invented tags. This makes templates less readable and thus worse maintainable.

    @ThingsExpo Stories
    Just over a week ago I received a long and loud sustained applause for a presentation I delivered at this year’s Cloud Expo in Santa Clara. I was extremely pleased with the turnout and had some very good conversations with many of the attendees. Over the next few days I had many more meaningful conversations and was not only happy with the results but also learned a few new things. Here is everything I learned in those three days distilled into three short points.
    As organizations realize the scope of the Internet of Things, gaining key insights from Big Data, through the use of advanced analytics, becomes crucial. However, IoT also creates the need for petabyte scale storage of data from millions of devices. A new type of Storage is required which seamlessly integrates robust data analytics with massive scale. These storage systems will act as “smart systems” provide in-place analytics that speed discovery and enable businesses to quickly derive meaningful and actionable insights. In his session at @ThingsExpo, Paul Turner, Chief Marketing Officer at...
    DevOps is about increasing efficiency, but nothing is more inefficient than building the same application twice. However, this is a routine occurrence with enterprise applications that need both a rich desktop web interface and strong mobile support. With recent technological advances from Isomorphic Software and others, rich desktop and tuned mobile experiences can now be created with a single codebase – without compromising functionality, performance or usability. In his session at DevOps Summit, Charles Kendrick, CTO and Chief Architect at Isomorphic Software, demonstrated examples of com...
    In his General Session at 17th Cloud Expo, Bruce Swann, Senior Product Marketing Manager for Adobe Campaign, explored the key ingredients of cross-channel marketing in a digital world. Learn how the Adobe Marketing Cloud can help marketers embrace opportunities for personalized, relevant and real-time customer engagement across offline (direct mail, point of sale, call center) and digital (email, website, SMS, mobile apps, social networks, connected objects).
    The Internet of Everything is re-shaping technology trends–moving away from “request/response” architecture to an “always-on” Streaming Web where data is in constant motion and secure, reliable communication is an absolute necessity. As more and more THINGS go online, the challenges that developers will need to address will only increase exponentially. In his session at @ThingsExpo, Todd Greene, Founder & CEO of PubNub, exploreed the current state of IoT connectivity and review key trends and technology requirements that will drive the Internet of Things from hype to reality.
    Two weeks ago (November 3-5), I attended the Cloud Expo Silicon Valley as a speaker, where I presented on the security and privacy due diligence requirements for cloud solutions. Cloud security is a topical issue for every CIO, CISO, and technology buyer. Decision-makers are always looking for insights on how to mitigate the security risks of implementing and using cloud solutions. Based on the presentation topics covered at the conference, as well as the general discussions heard between sessions, I wanted to share some of my observations on emerging trends. As cyber security serves as a fou...
    Continuous processes around the development and deployment of applications are both impacted by -- and a benefit to -- the Internet of Things trend. To help better understand the relationship between DevOps and a plethora of new end-devices and data please welcome Gary Gruver, consultant, author and a former IT executive who has led many large-scale IT transformation projects, and John Jeremiah, Technology Evangelist at Hewlett Packard Enterprise (HPE), on Twitter at @j_jeremiah. The discussion is moderated by me, Dana Gardner, Principal Analyst at Interarbor Solutions.
    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.
    The Internet of Things is clearly many things: data collection and analytics, wearables, Smart Grids and Smart Cities, the Industrial Internet, and more. Cool platforms like Arduino, Raspberry Pi, Intel's Galileo and Edison, and a diverse world of sensors are making the IoT a great toy box for developers in all these areas. In this Power Panel at @ThingsExpo, moderated by Conference Chair Roger Strukhoff, panelists discussed what things are the most important, which will have the most profound effect on the world, and what should we expect to see over the next couple of years.
    With all the incredible momentum behind the Internet of Things (IoT) industry, it is easy to forget that not a single CEO wakes up and wonders if “my IoT is broken.” What they wonder is if they are making the right decisions to do all they can to increase revenue, decrease costs, and improve customer experience – effectively the same challenges they have always had in growing their business. The exciting thing about the IoT industry is now these decisions can be better, faster, and smarter. Now all corporate assets – people, objects, and spaces – can share information about themselves and thei...
    PubNub has announced the release of BLOCKS, a set of customizable microservices that give developers a simple way to add code and deploy features for realtime apps.PubNub BLOCKS executes business logic directly on the data streaming through PubNub’s network without splitting it off to an intermediary server controlled by the customer. This revolutionary approach streamlines app development, reduces endpoint-to-endpoint latency, and allows apps to better leverage the enormous scalability of PubNub’s Data Stream Network.
    I recently attended and was a speaker at the 4th International Internet of @ThingsExpo at the Santa Clara Convention Center. I also had the opportunity to attend this event last year and I wrote a blog from that show talking about how the “Enterprise Impact of IoT” was a key theme of last year’s show. I was curious to see if the same theme would still resonate 365 days later and what, if any, changes I would see in the content presented.
    Apps and devices shouldn't stop working when there's limited or no network connectivity. Learn how to bring data stored in a cloud database to the edge of the network (and back again) whenever an Internet connection is available. In his session at 17th Cloud Expo, Ben Perlmutter, a Sales Engineer with IBM Cloudant, demonstrated techniques for replicating cloud databases with devices in order to build offline-first mobile or Internet of Things (IoT) apps that can provide a better, faster user experience, both offline and online. The focus of this talk was on IBM Cloudant, Apache CouchDB, and ...
    Microservices are a very exciting architectural approach that many organizations are looking to as a way to accelerate innovation. Microservices promise to allow teams to move away from monolithic "ball of mud" systems, but the reality is that, in the vast majority of organizations, different projects and technologies will continue to be developed at different speeds. How to handle the dependencies between these disparate systems with different iteration cycles? Consider the "canoncial problem" in this scenario: microservice A (releases daily) depends on a couple of additions to backend B (re...
    There are over 120 breakout sessions in all, with Keynotes, General Sessions, and Power Panels adding to three days of incredibly rich presentations and content. Join @ThingsExpo conference chair Roger Strukhoff (@IoT2040), June 7-9, 2016 in New York City, for three days of intense 'Internet of Things' discussion and focus, including Big Data's indespensable role in IoT, Smart Grids and Industrial Internet of Things, Wearables and Consumer IoT, as well as (new) IoT's use in Vertical Markets.
    Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud, to a world of hybrid cloud, and to a world dominated by the APIs that make today's multi-cloud environments and hybrid clouds possible. In this Power Panel at 17th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the importance of customers being able to use the specific technologies they need, through environments and ecosystems that expose their APIs to make true change and transformation possible.
    Container technology is shaping the future of DevOps and it’s also changing the way organizations think about application development. With the rise of mobile applications in the enterprise, businesses are abandoning year-long development cycles and embracing technologies that enable rapid development and continuous deployment of apps. In his session at DevOps Summit, Kurt Collins, Developer Evangelist at, examined how Docker has evolved into a highly effective tool for application delivery by allowing increasingly popular Mobile Backend-as-a-Service (mBaaS) platforms to quickly crea...
    The Internet of Things (IoT) is growing rapidly by extending current technologies, products and networks. By 2020, Cisco estimates there will be 50 billion connected devices. Gartner has forecast revenues of over $300 billion, just to IoT suppliers. Now is the time to figure out how you’ll make money – not just create innovative products. With hundreds of new products and companies jumping into the IoT fray every month, there’s no shortage of innovation. Despite this, McKinsey/VisionMobile data shows "less than 10 percent of IoT developers are making enough to support a reasonably sized team....
    The cloud. Like a comic book superhero, there seems to be no problem it can’t fix or cost it can’t slash. Yet making the transition is not always easy and production environments are still largely on premise. Taking some practical and sensible steps to reduce risk can also help provide a basis for a successful cloud transition. A plethora of surveys from the likes of IDG and Gartner show that more than 70 percent of enterprises have deployed at least one or more cloud application or workload. Yet a closer inspection at the data reveals less than half of these cloud projects involve production...
    Internet of @ThingsExpo, taking place June 7-9, 2016 at Javits Center, New York City and Nov 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA, is co-located with the 18th International @CloudExpo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world and ThingsExpo New York Call for Papers is now open.