In the first blog post of this multi-part blog series, we described how integration into an Enterprise Business Bus (ESB) does not need to be implemented using proprietary interfaces exposed by the ESB vendor. Instead, we are encouraging you to take control of your side of the integration by requesting a decoupled implementation.
The reason for this recommendation is that it puts your team in the driver’s seat of the integration design and development. During design, a decoupled integration only requires that the two sides agree on a single contract with a minimum of details. During implementation, there is no need to learn vendor-specific interfaces, but rather your side of the integration uses your technology of choice.
RESTful and CIMple Implementation: A Plethora of Standards
In this article we encourage implementing decouple integration using industry standards: particularly those related to REST and CIM. The adherence to standards will ensure that your side of the integration relies on proven patterns, and robust technologies. Also it will make the implementation more transparent to your team, and to the ESB integrator. In essence, a RESTful and CIMple implementation will empower your team to take control of your ESB integration.
RESTful Design
REST (REpresentational State Transfer) is the software architecture of the World Wide Web. As such, it reaps the benefits from the most successful distributed computing platform ever developed, the “Web”; superseding by far other technologies such as RPC, LPC, DCOM, and ODBC, to name a few. Adopting REST as the architecture for an integration is a “no brainer”… We are all using the “Web” to manage our bank accounts, to buy stuff, to check the weather, to watch the news… And we do it with ease and confidence. Why not let our systems integrate in a similar manner?
REST is all about sharing resources among systems. Resources being objects such as Web pages, pictures, video files, anything that can be represented in a computer-based system. REST allows for many ways to represent the resources, and the XML standard is a favorite; with JSON becoming even more popular. Resources are shared among systems with the aid of RESTful services which:
- Use HTTP as the communication protocol.
- Send and receive XML messages, defined by XSD schemas.
- Identify resources via URIs (URLs).
- Present a Uniform Interface.
- And are by nature stateless.
A Simplistic Example
Let us now illustrate these concepts with an example. Say that a Work Management System (WMS) interacts with a Geographic Information System (GIS) so that a work order in WMS is given a geographic location from GIS, and that a “flag” marker is placed on the GIS map with a label indicating the ID of the WMS work order.
To provide this functionality, the WMS displays an embedded map so that during creation of a work order the user clicks the map to choose the job location. (In a real application, there are many resources, and many interactions associated with these resources to accomplish a practical WMS/GIS integration; but for the purpose of the example let us be simplistic.)
Note that this application is easily represented as a request/response pattern within a service Oriented architecture (SOA). The GIS services the request of its client, the WMS, by placing a labeled flag with work order information in the location chosen by the user.
The first step in a RESTful implementation is to identify resources. Here we identify just one GIS service resource: a Labeled Flag displaying the work order ID, located at the selected coordinates.
Second, we choose a REpresentation for the resources. Let it be in XML:
Third, we implement the service request via HTML standard PUT method. The client application, WMS, may simply trigger this HTTP method once the point is clicked in the displayed map during creation of the work order. There are many software development environments that will provide with an HTTP-standard API. Execution of your client request results in the following HTTP message:
- VERB -> PUT for this example.
- URI -> /SimpleGISServer/LabeledFlags
- HTTP Version -> 1.1
- Optional REQUEST HEADER -> “void” in this example.
- REQUEST BODY -> XML message with LABELED_FLAG resource request details.
Then, without further effort, the HTTP protocol carries the request over the TCP/IP network. Because the HTTP message uses URIs (URLs) to identify resources, TCP/IP finds the end-point specified in the URI, and commands the server to execute the requested service, LabeledFlags, with the provided resource.
Another advantage of HTTP-compliance is that regardless the success or failure in execution of the service, the HTTP protocol takes care of replying to the client with an HTTP status code. For instance 200 OK for success, or the infamous 4xx Client and 5xx Server errors; among others.
Once again, HTTP supports a Uniform Interface for responses:
- HTTP Version -> 1.1
- HTTP Status Code; 200 OK
- Optional RESPONSE HEADER -> “void” in this example.
- Optional Response BODY -> XML message with response details; format depends on application.
Finally, a RESTful implementation based on HTTP is stateless; i.e., servers do not maintain the application state for any client. Thus, your requests cannot depend on previous requests, or their responses. And, in many applications that is what you want from your integration, particularly when following a master/slave pattern.
Let me explain… In an integration one or several applications act as systems of record for specific sets of data. When a system of record PUTs data in another application the system of record can be model as a master commanding the other application, the slave, to accept the data.
Regardless of whether the data is successfully processed by the slave or not, the master should not care, and continue with its own operation. (Error logging then becomes paramount, so that administrators can figure out whether the integration is failing.) Because of this master/slave pattern, we can expect a RESTful decoupled systems integration to be asynchronous; freeing this way many resources, and improving operability.
Conclusion
By adhering to a RESTful implementation you are secured a robust, standards-compliant systems integration. Also, this integration is completely decoupled, in the sense that your side of the integration does not need to know the details of the ESB, or of the services being exposed by the target application.
Since you do not need knowledge of the ESB vendor software to implement a RESTful integration, and since REST, as well as HTTP, TCP/IP, XML, Web Services, and others, are well known technologies, you may now feel empowered to take control of your ESB integration.
Note that the RESTful contract tightens the implementation requirements to ensure two way communication with minimum details:
- HTTP protocol
- TCP/IP communication
- XML data format
- URI (URL) identified end-points
- Statelessness and a-synchronicity.
If the HTTP Uniform Interface, with a precise collection of HTTP VERBs seems too constraining for your application, fear not. The rigidity in the VERBs, which ensures uniformity, is compensated by the flexibility offered by the HTTP message body: whether request or response. With its free format, only constrained to be an XML message, you can embed in the body of the message any functionality, no matter how complex, offered by your server’s RESTful services.
A study of how to exploit this flexibility focuses on the contents of your body payloads. And here is where you can impose another standard to your messages: CIM.
In a future article I will explain the details of a decouple integration using CIM messages as the payloads of your HTTP requests and responses. Your integration will turn out to be RESTful and CIMple. Stay tuned.
What do you think?