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 json.org)

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.

Orchestration

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 steve@portaltown.com.

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

This was last published in January 2015

Dig Deeper on Managing microservices architectures and SOA

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Have you used a rich JavaScript client to exchange data with microservices?
Cancel
We have, but mostly for smaller applications. We've been using SOA techniques for quite a while, and that's really what microservices are - essentially the same thing as SOA, but with agile development principles - rapid initial development, small incremental advances vs giant projects, and so on. The cool thing about microservices with JavaScript is that you don't necessarily need an application server. The potential downside is security, but that can be mitigated with the proper approach.
Cancel
Thanks for sharing, timethy. Glad to learn you've had success with microservices. Do you think you'll use it for larger applications in the future?
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close