sommai - Fotolia

Get started Bring yourself up to speed with our introductory content.

How to use a rich JavaScript client to exchange info with microservices

Microservices can be used to address a number of issues, including a synchronous response to requests.

Over the past two decades, heavy middle tiers have given way to distributed, thick JavaScript clients written against RESTful services. This shift allowed Web applications to appear and behave more similarly to standalone network applications. The AJAX/REST model still retained some limitations, however, including a synchronous response to a request.

Microservices can address many of these problems. Although the term has no canonical definition, microservices are considered to be highly specialized services that address a specific functional need. Because of their highly focused nature, microservices require increased attention to requirements, such as orchestration, real-time message, handling multiple asynchronous responses, service scheduling and security. Besides being important requirements for almost every network application, they are especially relevant when working with a microservices architecture. In this real-world example, learn how to use a rich JavaScript client to bidirectionally exchange information with multiple microservices architectures.

The tools

The toolkit consists of two open-source frameworks: the Dojo toolkit and the CometD Messaging Server, used to create a basic Enterprise Service Bus (ESB).  Java is used in this example, but the concepts can be applied to any network-friendly programming language.  The ESB will handle the processing and routing of the messages returned from the microservices.

The components

Microservices are considered to be highly specialized services that address a specific functional need.

The example application has three basic components:

           1) The JavaScript client, written using Dojo

           2) The CometD Messaging Server, written in Java

           3) The ESB, also written in Java

The key concept is asynchrony beyond the 1:1 relationship of request-response and messaging.  The JavaScript user interface (UI) client handles arbitrary action requests in the form of a JSON payload, and sends them as a message on the messaging channel. Other listeners on the channel (microservices in this example) receive the messages, parse them and act accordingly. Inserting the messaging server into the architecture changes the landscape dramatically, allowing the ESB or other listeners on the system to send both data and human-readable messages throughout the interim of the process, allowing for more granular control than a simple, single response to a request.

The UI, using Dojo toolkit and Comet D

Real-time messaging (browser push) was implemented to enable asynchronous communication from the client user interface. The client creates messages that would be acted upon by a subscriber, and then interacts with the appropriate set of microservices to query, store and analyze marketing information. The application's connection must be persistent; therefore, the Model View Controller pattern was used on the client side in the browser. The application launches, handshakes and subscribes to a message bus, at which point it can post and react to subsequent messages on the bus.

The application-specific microservice (Java Servlet and

The ESB lets anyone receive and act on the messages, thus allowing the load to be easily distributed.  All communication in this example is in JSON, allowing for a language- and platform-agnostic communication. To simplify development and maintenance, and to provide security, a set of microservices was developed using a REST implementation. Fundamentally, the application needs to input a set of attributes that would be applied to multiple microservices simultaneously. The sample REST services provide:

  1. Authentication token validation and generation
  2. Access to external microservices to create, retrieve, store and analyze information
  3. The ability to access several third-party microservices simultaneously 

Commercial microservices

Many microservices are provided free online, but there are also commercial providers. For example, some services remove the onus of local (or intranet) data persistence, allowing focus to be placed on application functionality.  Most applications need to store and retrieve data, a requirement that can become costly or time-consuming (especially for a simple proof-of-concept), and can potentially dictate the overall architecture of a network application. This example is different in that it abstracts data storage and manipulation functionality entirely, allowing the end user to use appropriate microservices for this task without including additional persistence code in the architecture.

When working with external services, there typically is some sort of authentication protocol. Here, it's possible to see the advantages of abstracting the client UI from any given REST service. For this example, the token is time-sensitive. This token would be generated with the REST service and authenticated with the remote microservice. Given the environment, any number of REST services can maintain their respective security tokens, allowing the JavaScript client to focus solely on presentation and display.


One of the best features of the environment described is that all services are entirely decoupled from one another, and thus abstracted from the specifics of microservice API implementations. In doing so, the SOA philosophy of small, transparent, modular and extensible services, distributing the footprint while maintaining scalability is adhered to. The result is a simple, fast, lightweight non-linear communication framework that is, in effect, carrying on a bidirectional, multi-tiered conversation with any number of microservices via the ESB.  This allows for a simple yet powerful and sophisticated thick client, capable of performing any type of action, including querying, storing, analyzing data, launching remote processes, interacting with other processes on the local intranet, and so on.  

Applications can go beyond a list of synchronously ordered requests and responses by using microservices and messaging to create a service-oriented architecture. Using tools such as CometD, Dojo toolkit and Java make it easy to develop a truly asynchronous design that will improve the user experience and make the code easier to support and maintain.

About the author:
Steve Harris has his B.S. from Washington State University in Computer Science. He has over 25 years of experience developing software. Steve has extensive background in service-oriented architectures and ECMAScript variant languages. He currently resides in Colorado where he enjoys outdoor activities with his family. Steve can be contacted at [email protected].

Follow us on Twitter @SearchSOA and like us on Facebook.

Dig Deeper on Distributed application architecture