Enterprise Integration Zone is brought to you in partnership with:

Willie Wheeler is a Principal Applications Engineer with Expedia, working on continuous delivery, including build automation, test automation, configuration management and application performance management. He's also the lead author of the book Spring in Practice (Manning). Willie is a DZone MVB and is not an employee of DZone and has posted 23 posts at DZone. You can read more from them at their website. View Full User Profile

When Building a CMDB, Separate the UI From the API

08.07.2012
| 4284 views |
  • submit to reddit

One lesson I’ve learned in building CMDBs is to cleanly separate the UI from the web service API. In the Java world, for example, this means that the API should be its own package (e.g., WAR file). The UI should be separate, whether that’s a separate WAR, a rich client (Flex, JavaFX, etc.), GWT app, or whatever. Various configuration and release management tools (e.g., uDeploy, DeployIt, Chef) work in this fashion, and with good reason. Here are some advantages of the approach.

Keeps everything automatable. This is by far the most important benefit. Ultimately you’re establishing a CMDB because you want to integrate and automate, so the data needs to be readily accessible to automation. If you treat the UI as just another client of a web service API, then you have an architecture that forces you to implement everything as a service, with the result that you can automate anything that the UI can do. And it will also force you to establish a proper discipline around defining and evolving the API, which is critical to your effort’s overall success.

Makes the API more robust. The CMDB’s API is the heart and soul of your devops platform, and cleaving away the UI makes the API more robust. Somebody won’t accidentally break the API while making a change to the UI.

Allows the UI and API to scale independently. In the early days it may be that most of what you do with your CMDB is user-driven, but the goal over time is once again to automate your environment. Eventually you should expect that your API will get lots of traffic because you have automation making all kinds of requests (reads and writes) against it, and the UI will receive significantly less use. It’s useful to be able to scale those independently since they have different expected load patterns.

Facilitates testing. In some cases it may be easier to test your API if the UI is separate. You don’t have to worry about interactions with UI components, UI configuration and the like.

Published at DZone with permission of Willie Wheeler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mark Unknown replied on Wed, 2012/08/08 - 8:55am

This is true of almost ALL applications. That being said, there is a difference between packaging and modularity (and i think you are confusing the two). Sometimes it makes sense to package the whole app together but still have it be modular. It all depends. What is "bad" is putting all your code in a single "project" (i.e. Eclipse Web project).  But not always. ;)  

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.