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.
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 example application has three basic components:
2) The CometD Messaging Server, written in Java
3) The ESB, also written in Java
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:
- Authentication token validation and generation
- Access to external microservices to create, retrieve, store and analyze information
- The ability to access several third-party microservices simultaneously
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.
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@example.com.