Java IoT Authors: Pat Romanski, Yeshim Deniz, Elizabeth White, Liz McMillan, Paul Simmons

Related Topics: Java IoT

Java IoT: Article

An API Developer's Primer

An API Developer's Primer

Of course, TAPI still has a niche and is indeed embedded into many PC modems, but its track record against its original goals is, shall we say, modest. Some would say that it never saw the Internet coming. Of course, technology development is almost Darwinian in the way it casts off also-rans. VRML promised us the world and is much cooler than HTML; Microsoft’s Blackbird would give us our information superhighway; JSDT would revolutionize application collaboration; Network PCs, BeOS, BetaMax…

With the Java Community Process starting approximately 150 Java API definitions now, it shouldn’t be surprising that not all of these will succeed. InfoBus 2.0, for instance, was withdrawn. Of course, success can be measured in different ways, and for some APIs even narrow adoption is appropriate. That said, some are bound to fail when judged against their original goals. Obviously JDBC and EJB are resounding successes, but what of JTAPI or JavaSpaces or Java Speech API? This article looks at what makes a good API, what pitfalls should be avoided, and who the winners and losers are.

Case Studies
Here’s a sampling of Java APIs that have suffered from less than overwhelming adoption or are fraught with potential problems:

The Java Speech API targeted the same market as Microsoft Windows’ SAPI. It basically offers capabilities for generating speech and performing speech-to-text. While the market has never been huge despite Corel’s inclusion of speech recognition in its Office Suite, there seemed to be some potential for a JSAPI. Unfortunately, the number of implementations is somewhere around two. Why?

Small market niche: Despite the hopes of speech recognition companies, this market is still small and specialized, with some inroads into automated directory assistance services.

No published API classes: Indeed the API is published not as a set of interfaces and classes that implementors code against, but as a document that must be implemented. This makes implementation more difficult, leads to a high likelihood of typographical errors, makes it hard to develop to the specification without a working implementation, and makes it very hard to plug two vendor implementations into one system.

Implementation isn’t decoupled from specification: Part of the reason the API classes and interfaces are not published as code is that the specification embeds the implementation in its definition. That is, there’s no concept of interfaces that a vendor writes to and plugs into an application using some factory method.

At the time of writing, the Preferences API (JSR #10) has been accepted as part of J2SE 1.4. Its intent to provide a better registry-like replacement for properties is long overdue and especially topical as the era of distributed Java applications through mobile devices and Web services gains a new life.

That said, the Preferences API currently contains one fatal flaw: it ties the persistence of part of an application’s state to a JVM. The Preferences class delegates its calls to a subclass of the AbstractPreferences class, which defines some Service Provider Interface (SPI) functions for completing the actual management of data between the application and the Preferences backing store.

Like AWT, the determination of which SPI will be instantiated behind the Preferences class is left up to the JVM implementation (a Java Property: java.util.prefs.Preferences-Factory is suggested, but not mandated). This means that an application has no way of plugging in an appropriate Preferences implementation – a networked implementation for an applet and a local registry for an application. Needless to say, it can’t plug two implementations into the same application.

Most troubling, since the Preferences backing store is tied to the JVM implementation, you’ll lose all your Preferences if you change JVMs. Sure, there’s support for exporting and importing Preferences, but this would require users to manually migrate Preference information when they want to change their JVM vendor. Depending on your system “path,” an application that can also run as an applet may not be able to share preferences between run types. It’s one thing for the AWT to tightly tie the implementation to a JVM – GUIs are a transient aspect of an application after all – it’s quite another to bind a persistence implementation to a JVM. On servers, in particular, it’s not unusual to have several JVMs resident with different performance characteristics.

JTAPI started development in 1996 as a uniform way for applications to access telephony services, hard on the heels of TSAPI and TAPI in the “C” world. Since that time it has been through several revisions and, at the time of writing, the current release is 1.3. Unfortunately, even after all this time, the number of available JTAPI implementations can probably be counted on one hand. Some are only test frameworks that offer no real telephony access and, among the one or two released by reputable telephony companies, it’s not unusual for them to “modify” the standard.

Why didn’t it take off? Well, there are a number of reasons.

Complex API
JTAPI has to be one of the most complex APIs around, consisting of 19 packages with over 250 interfaces to implement. Implementing and maintaining all, or even part, of this is a major undertaking, which can only be justified by significant developer demand. This becomes a vicious circle: no applications mean no incentive to invest in JTAPI implementations, and with few implementations there’s little incentive to build applications.

Optional Hell
JTAPI allows most packages to be optional, meaning a vendor doesn’t have to implement them. On top of this, even within interfaces, many methods are also optional, permitted to raise the “MethodNotSupported” exception. While an obvious side-effect of trying to map a unified API to a complex and nonstandard industry feature set, this causes two problems. For JTAPI implementors, we must now try to predict our client requirements and trade that off against development complexity in order to determine which features to support. We must also implement a whole “Capabilities” framework to expose our feature set. For application developers, it provides extra uncertainty since it’s not guaranteed that we’ll be able to plug in multiple vendors to support our application.

The whole promise of JTAPI was decoupling applications from telephony providers, but in reality all it does is provide a common development paradigm for building Java telephony applications, since finding two JTAPI vendors with a set of intersecting features that match an application’s requirements is rather hard (actually, finding two JTAPI implementations of any kind is no easy feat).

Shifting Sand
Successful APIs offer gradual improvements. Unfortunately, JTAPI 1.3 saw listeners replace observers and a wholesale change in the way media was controlled. Even worse, while listeners were added to the core JTAPI package, subpackages such as “call control” didn’t have listeners added yet. So, to receive “call control” and “core” call events, you either have to add both an observer and a listener to the call or just add an old style, deprecated observer.

Broken Standard
As was mentioned in the previous point, JTAPI changed the way media was controlled in 1.3. Unfortunately, the 1.3 API was rushed out before it was properly completed, as can be seen by the simple fact that the “media” API can’t be implemented.

To control media, an application should instantiate a “MediaService” implementation, which by necessity must be tied into the JTAPI implementor’s private code. But there’s no “Factory” capability defined in the API, only a “Basic-MediaService” class for subclassing. But BasicMediaService extends “NullMediaService” and so can’t be tied easily to a real implementation. Real implementations are forced to replace the JTAPI API classes or provide proprietary solutions. Thankfully this is being fixed in JTAPI 1.4.

Lack of CTI Market
The Computer Telephony Integration (CTI) market, like many high-tech startups, is always “just about to explode.” Maybe the arrival of the Internet has taken away the original vision of CTI. Nevertheless, while this is not a problem as we can attach to JTAPI directly, it does highlight how a complex API combined with a nonexistent market is a death blow.

No Vendor Support
JDBC offers a vendor-neutral view of relational data, and RDBMS vendors (and third parties) have endorsed it heartily. After all, what good is a database if applications can’t access it? In addition, database vendors tend to market their products based on performance, price, and reliability.

The telephony market is very different. Telephony vendors market on feature sets (“Vendor X may support ‘Park’, but we support ‘Park’ and ‘Camp-on’”), regardless of how few users know how to press the right combination of “*”, “#”, and numbers to use the features. A telephony system without application access is, well, still a telephony system. Considering the complexity of JTAPI, there’s no compelling reason for most vendors to implement it.

No Reference Implementation
JTAPI has never provided a reference implementation against, for example, TAPI in win32. This leads to legions of frustrated developers flooding the JTAPI mailing list with questions about where they can get an implementation to run their code against. Eventually they go away and the potential vendors have no set of JTAPI applications to justify development of a JTAPI implementation. Chicken and egg. Even though the Java Community Process now requires reference implementations for Java Specification Requests, this requirement was unfortunately waived for JTAPI 1.4.

Fragmented Market
Finally, we should note that JTAPI is not even the only telephony API being developed under the Java Community Process. There’s also a Parlay-based “service provider application” API and Jain Jcc and JCAT.

Despite this litany of problems, there may be some hope on the horizon. Recently there has been a push to rationalize the Jcc, Parlay, and JTAPI APIs so they’re not isolated islands but build off each other. More important, JCC/JCAT is targeting the ongoing convergence of voice-into-network services and this is a space in which Java is attractive to implementers, much as Java has become firmly entrenched in the application server market. JCC/JCAT not only targets a real and growing market, it’s also cut down significantly on the size of the API that vendors must implement. And JCC has been released with a reference implementation, so maybe the lessons are being learned.

Avoiding Pitfalls
These three case studies illustrate some of the problems that can doom an API to marginal use. It’s important to understand these if we don’t want to repeat past mistakes. Even in an internal development effort, a company will want to ensure that any reusable framework being developed for internal usage will be used, or else why put money into developing it?

1. Make sure the framework has a market: VRML is a cool technology, but no one could figure out how it could provide value to users.

2. Make sure the API has vendors: If you’re developing an API to interact with telephony systems, the vendors of those systems are not going to write implementations to your API unless they want your users and are willing to conform to a standard. After all, in some markets, vendors sell based on their differences from other vendors, not their compatibility.

3. Entrenched opposition: Systems change slowly and you must show a significant benefit over existing systems in order to convince developers to risk moving to a new API. Databases are a case in point. Corporations have a large investment in relational databases and JDBC is mature, so any object-oriented API that connects to an object database is fighting an uphill battle

4. Complexity: There’s always a tradeoff between power and simplicity. Try to enable developers and service provider implementors with a minimal set of core features.

Winners and Losers
Let’s cut to the chase. Which APIs have failed to meet expectations and why? Note that Table 1 is a subjective list and I’m sure I’ll take abuse for it. Furthermore, while some of these APIs have failed for technical reasons, often the source of failure has as much or more to do with shifts in the technology market.

This list is by no means exhaustive, but it does give you some idea of which APIs have taken the right steps. The success of Java on the server has also tilted the balance in favor of server-side APIs such as JSP, EJBs, and JNDI. Some APIs, such as Swing, generate such a vigorous debate that they can only be described as flawed successes.

The Case for Some Guidance
One of the most striking things about the Java APIs, once you’ve dug into the details, is the lack of consistency in their design decisions. Since each API has been developed by its own team, with only limited overall guidance, maybe this shouldn’t be surprising. Some teams choose to support pluggable implementations using an explicit Factory pattern (e.g., JTAPI), others hide the factory behind an obscure system property (e.g., AWT peers), while yet others use a URL lookup of registered providers (e.g., JDBC).

This means that developers must learn the usage paradigm of each API separately and usually can’t take that usage pattern knowledge with them when they move to a new API. Now maybe this is justified – I do expect to have more control over what database driver to use than how the AWT renders my widgets – but nevertheless a little bit more consistency wouldn’t hurt.

While the JCP does have a steering committee, it seems limited in its ability to approve APIs and resolve API overlaps. Java would benefit from a steering committee that provided an overall pattern framework for the APIs. For instance, they may define the preferred patterns for plugging vendor implementations into an API using a Factory pattern.

Under the Java Community Process 2, the process has been updated to correct some flaws in the original. In particular, JCP 2.0 requires that both a reference implementation and a compatibility toolkit be produced for the API. The requirement for a reference implementation has been successfully used before by the OMG in its CORBA standards and helps to spur on developers; this in turn makes vendors more interested in implementing the API. A reference implementation also ensures that an API is feasible. Similarly, a compatibility toolkit helps to keep API implementations from fragmenting. Unfortunately, the JCP 2.0 came along too late for JSAPI and JTAPI.

Even with these improvements, there are still some areas where the JCP could be improved. The JCP works on a consensual model, as opposed to the OMG adversarial model of Request for Comments and Request for Proposals. While this can speed up API development, in the real world it can also stifle options. Usually the specification lead comes from the group that first proposed the API, and it’s not surprising that they may come into the process with some preconceived notions of an appropriate architecture.

Better and more consistent APIs might evolve if different groups could propose to the JCP Executive Committee (or better yet, a JCP Community Forum) alternative API architectures and patterns and have the API “direction” come under some competition. Once this high-level phase is resolved, the different sides could be brought together into a consensual group and proceed as they do now.

The Java Community Process has learned some valuable lessons since the JCP 1.0, but still it could benefit from better cohesion if:

• Platform design pattern standards were defined.

• More competition for initial API “architectures” was supported.

• A dependency map of technologies was clearly laid out (I depend on EJBs, which themselves use JNDI, so I can use JNDI without inflicting extra dependencies on my applications).

• All JSRs required a reference implementation.

• Optional packages and methods made up a minority of the API.

• APIs were accompanied by usable classes the developers can import into their development environment and code against.

Of course, this whole discussion also applies to the creation of APIs by other parties, internal to an organization or not. Using RFPs in the development of a proprietary API might not make as much sense, however. And getting open source projects organized enough to adopt RFPs on a wide scale may be a bit optimistic.

Despite my criticisms, I should point out that the standard Java APIs, like many proprietary APIs and APIs in other languages, are the result of a lot of hard work by bright people. When an API is flawed, as opposed to just not adopted widely, it’s often due to the lack of an overall guiding framework that ensures that the API works well with other APIs and fits into a coherent usage paradigm. For a successful API, here are some simple rules:

1. Find an industry niche with a high value for developers, high enough to offset the extra cost of learning a new API. An example is JDBC. Of course, as the Java “platform” matures, these niches tend to get narrower and narrower until a new technology bursts on the scene (e.g., XML, SOAP).

2. Hide complexity from the user of the API, but not so much complexity that the API is hard to implement. The harder it is for vendors to implement, the fewer implementations there will be. This prevents developers from using it, which in turn discourages vendors from implementing it. Both JTAPI and JSAPI (speech) have suffered from a dearth of implementations, partly due to the complexity of the API implementation. On the other hand, HTML and HTTP are examples of standards that are wildly successful because they were just complex enough to be useful.

3. Ensure that the vendors are there. While telephony vendors were actively involved in developing JTAPI, there wasn’t a lot of incentive for them to actually build implementation. Traditional PBXes and Switches have been marketed on their differentiating features instead of performance, quality, or price, which doesn’t lead telephony companies to want to present an API that hides this differentiation.

4. When choosing between sticking to a widely adopted pattern or implementing a “better” but unusual pattern, stick to the pack. There are various pluggability patterns employed by APIs to hook applications to API implementations, such as a Factory pattern or registry, broker, or system property. Unfortunately, there are too many of them.

5. When an API manages the persistent aspects of an application, ensure that it’s not tightly tied to the JVM. It’s one thing for AWT to be tightly bound to the JVM, quite another for the Preferences API to be bound to the JVM.

Parting Shot
While I’ve concentrated on the well-known Java Community Process APIs (familiar to most developers), the same lessons apply to internal proprietary APIs as well as non-Java APIs. The pitfalls and lessons discussed here apply just as much to internal development efforts as to public ones. After all, even inside a company a successful API still has customers who must be kept happy.

The current rush to XML standards – which are not programming APIs but data formats – provides an eerie parallel to this discussion. In fact, in reviewing the debris being left on the Java API highway, it becomes obvious that while there are technical errors, the most common reason an API dies or doesn’t reach its anticipated potential is that the technology market shifts, leaving InfoBus and JAF wondering what happened to visual JavaBean assemblers even as the market moved toward server-side Java.

There’s nothing about Java, compared to other languages or platforms, that has led to poorer APIs, and a lot has improved. Object-oriented code enables easy pluggability, interfaces provide nice decoupling between the API and the implementation, and packages are extremely useful name-space separators. If I appear critical of Java APIs, it’s like the criticism you may give to a beloved child. Since mistakes are always easier for armchair critics to find afterwards, it should be noted again that most Java APIs are well crafted and that the efforts of the API designers is and has been diligent and thoughtful.

But there’s always room for improvement.


JSAPI: http://java.sun.com/products/java-media/speech/

Preferences API: http://java.sun.com/j2se/1.4/docs/guide/lang/preferences.html and www.jcp.org/jsr/detail/10.jsp

JTAPI: http://java.sun.com/products/jtapi/index.html

InfoBus: http://java.sun.com/products/javabeans/infobus/

• JavaBeans Activation Framework: http://java.sun.com/products/javabeans/glasgow/jaf.html

• JSDT: http://java.sun.com/products/java-media/jsdt/index.html

• JINI: www.jini.org/

• JavaSpaces: http://java.sun.com/products/javaspaces/

• Open Service Gateway Specification: www.jcp.org/jsr/detail/8.jsp

• Orthogonal Persistence: www.jcp.org/jsr/detail/20.jsp

• JSP: http://java.sun.com/products/jsp/

• Servlets: http://java.sun.com/products/servlet/index.html

• EJB: http://java.sun.com/products/ejb/index.html

• XML: http://java.sun.com/xml and http://java.sun.com/xml/jaxp/index.html


InfoBus 2.0, JavaBeans Activation Framework
•    While JavaBeans are a great way of providing a pattern for IDEs to use to inspect arbitrary widgets, the InfoBus idea of hooking these together through an asynchronous data bus never really caught on with developers or tool vendors. It’s simply too easy to wire bean events to event handlers that manipulate other beans directly through code. Similarly, the JAF, while not technically flawed, envisioned a role for Java that has not materialized.

•    Market for distributed media Java applets and applications is small
•    Competes with RMI and CORBA as yet another distribution infrastructure

Open Service Gateway Specification
•    No pressing need
•    Home networks are generally run by tech-savvy types who prefer the mature facilities provided by a Linux box

Orthogonal Persistence
•    Object databases are a niche market
•    Competes with Java data objects


•    Small market
•    No reference implementation
•    No interfaces to build against

•    No reference implementation
•    Too complex
•    No incentive for vendors
•    Inconsistent and broken API

•    Couples an application’s persistent state to a JVM implementation

JINI, JavaSpaces
•    Yet another distribution framework
•    Cool idea but no driving need


•    Targeted a need for server-side page generation with a clean language and server portability

•    Popular on the server due to platform independence and vendor neutrality
•    Provides standard to unify server application framework that was already evolving to meet the need

XML Parser
•    Hot technology
•    Pluggable architecture

•    Bridge to corporate data that drives many applications
•    Vendor-neutral
•    Vendors have incentive to provide drivers since they need applications to have access to their databa

Collections Framework   
•    While there was some controversy when the Collections Framework was being developed, especially for its refusal to reuse the popular JGL, it has succeeded due to its simplicity and, most important, its inclusion as a core Java package.

•    Ties into a popular industry niche of naming and directory services with a flexible and simple API. It doesn’t hurt that the wildly popular EJB standard uses JNDI as its discovery mechanism.

More Stories By Richard Deadman

Richard Deadman is a consultant in distributed Java systems with interests in meta-information and dynamic business logic. He received his Masters in Computer Science in 1991 and jumped from Smalltalk to Java in 1995. Since then, Richard has lead large Java enterprise development teams, given talks on XML, published several articles and contributed to a book. He lives with his wife and four children in Ottawa, Ontario. He can be contacted at [email protected] or through his web site at http://www.deadman.ca

Comments (2) 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
Russell 03/31/03 02:23:00 PM EST

Well, now at least I know why some API are what they are and why they aren't what they should. Critical mass is required for alot of thing before they really explode. I believe it's not to late to have simple, straight forward and limited telephony access add on to any Java enterprise application.

Great job Richard.

hareem 01/19/03 03:28:00 PM EST
@ThingsExpo Stories
@DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22nd international CloudEXPO | first international DXWorldEXPO and will feature technical sessions from a rock star conference faculty and the leading industry players in the world.
"Akvelon is a software development company and we also provide consultancy services to folks who are looking to scale or accelerate their engineering roadmaps," explained Jeremiah Mothersell, Marketing Manager at Akvelon, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
As data explodes in quantity, importance and from new sources, the need for managing and protecting data residing across physical, virtual, and cloud environments grow with it. Managing data includes protecting it, indexing and classifying it for true, long-term management, compliance and E-Discovery. Commvault can ensure this with a single pane of glass solution – whether in a private cloud, a Service Provider delivered public cloud or a hybrid cloud environment – across the heterogeneous enter...
DXWorldEXPO LLC announced today that ICC-USA, a computer systems integrator and server manufacturing company focused on developing products and product appliances, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City. ICC is a computer systems integrator and server manufacturing company focused on developing products and product appliances to meet a wide range of ...
More and more brands have jumped on the IoT bandwagon. We have an excess of wearables – activity trackers, smartwatches, smart glasses and sneakers, and more that track seemingly endless datapoints. However, most consumers have no idea what “IoT” means. Creating more wearables that track data shouldn't be the aim of brands; delivering meaningful, tangible relevance to their users should be. We're in a period in which the IoT pendulum is still swinging. Initially, it swung toward "smart for smart...
Headquartered in Plainsboro, NJ, Synametrics Technologies has provided IT professionals and computer systems developers since 1997. Based on the success of their initial product offerings (WinSQL and DeltaCopy), the company continues to create and hone innovative products that help its customers get more from their computer applications, databases and infrastructure. To date, over one million users around the world have chosen Synametrics solutions to help power their accelerated business or per...
Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and ...
Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT staff augmentation services for software technology providers. By providing clients with unparalleled niche technology expertise and industry experience, Chetu has become the premiere long-term, back-end software development partner for start-ups, SMBs, and Fortune 500 companies. Chetu is headquartered in Plantation, Florida, with thirteen offices throughout the U.S. and abroad.
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
"We are a well-established player in the application life cycle management market and we also have a very strong version control product," stated Flint Brenton, CEO of CollabNet,, in this SYS-CON.tv interview at 18th Cloud Expo at the Javits Center in New York City, NY.
It is of utmost importance for the future success of WebRTC to ensure that interoperability is operational between web browsers and any WebRTC-compliant client. To be guaranteed as operational and effective, interoperability must be tested extensively by establishing WebRTC data and media connections between different web browsers running on different devices and operating systems. In his session at WebRTC Summit at @ThingsExpo, Dr. Alex Gouaillard, CEO and Founder of CoSMo Software, presented ...
Most people haven’t heard the word, “gamification,” even though they probably, and perhaps unwittingly, participate in it every day. Gamification is “the process of adding games or game-like elements to something (as a task) so as to encourage participation.” Further, gamification is about bringing game mechanics – rules, constructs, processes, and methods – into the real world in an effort to engage people. In his session at @ThingsExpo, Robert Endo, owner and engagement manager of Intrepid D...
Recently, WebRTC has a lot of eyes from market. The use cases of WebRTC are expanding - video chat, online education, online health care etc. Not only for human-to-human communication, but also IoT use cases such as machine to human use cases can be seen recently. One of the typical use-case is remote camera monitoring. With WebRTC, people can have interoperability and flexibility for deploying monitoring service. However, the benefit of WebRTC for IoT is not only its convenience and interopera...
Michael Maximilien, better known as max or Dr. Max, is a computer scientist with IBM. At IBM Research Triangle Park, he was a principal engineer for the worldwide industry point-of-sale standard: JavaPOS. At IBM Research, some highlights include pioneering research on semantic Web services, mashups, and cloud computing, and platform-as-a-service. He joined the IBM Cloud Labs in 2014 and works closely with Pivotal Inc., to help make the Cloud Found the best PaaS.
Everything run by electricity will eventually be connected to the Internet. Get ahead of the Internet of Things revolution. In his session at @ThingsExpo, Akvelon expert and IoT industry leader Sergey Grebnov provided an educational dive into the world of managing your home, workplace and all the devices they contain with the power of machine-based AI and intelligent Bot services for a completely streamlined experience.
Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...
Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
Personalization has long been the holy grail of marketing. Simply stated, communicate the most relevant offer to the right person and you will increase sales. To achieve this, you must understand the individual. Consequently, digital marketers developed many ways to gather and leverage customer information to deliver targeted experiences. In his session at @ThingsExpo, Lou Casal, Founder and Principal Consultant at Practicala, discussed how the Internet of Things (IoT) has accelerated our abilit...
In his session at Cloud Expo, Alan Winters, U.S. Head of Business Development at MobiDev, presented a success story of an entrepreneur who has both suffered through and benefited from offshore development across multiple businesses: The smart choice, or how to select the right offshore development partner Warning signs, or how to minimize chances of making the wrong choice Collaboration, or how to establish the most effective work processes Budget control, or how to maximize project result...