By the way, EMS means "Element Management System" in this context. It is not "Enterprise Management System" per se, though from what I understand of enterprise management systems, there are similarities, but there are differences too: namely, in the Telecom world, an EMS must have intimate knowledge of the devices it manages.
Anyway, on to the content...
Sunday, Jan 28, 2007: EMS on a Java EE application server?
I have never seen an EMS implemented on a Java EE application server, but I have heard of it being done. A friend at another company where they did this told me that it was overkill: the complex technologies behind J2EE overcomplicated the development of the EMS, and he thinks they would have saved time, money, and frustration rolling their own. But now that Java EE 5 is out, with its supposed simplifications, is it worth another look?
At my current company, we ignored the J2EE frameworks of years past and rolled our own EMS server framework, and it works well. And now, we’re so entrenched that any major architectural change would be difficult. However, would it make sense to evolve our architecture to be based on a Java EE application server? Or, considering my side-project of determining how I would write an EMS from scratch, would it make sense to do so on top of a Java EE application server? What would be the gain from doing so?
Java EE is great for 3-tier enterprise web applications, consisting of front end web-based client interfaces, middle-tier business logic, and a persistence tier. However, for an EMS, there is an additional component: the managed devices. And in some networks, especially access networks, there could be tens or hundreds of thousands of devices to configure, monitor, and keep secure. I think we would need a fourth tier: the device management tier. The device management tier would be responsible for interconnecting with the management interfaces on the devices themselves, using SNMP or whatever management protocol the devices support, and providing interfaces to the other tiers in the application server.
With a substantial portion of the EMS server application consisting of the device management tier, does Java EE still make sense? My current opinion: maybe. Today’s Java EE application servers claim to offer many features that would help with EMS functionality. The big ones include:
- Clustering support, which would support redundancy and scalability of the EMS server. It might even be useful for disaster recovery, with redundant EMS servers in geographically diverse locations. Rules frameworks, which would help in defining and enforcing complex configuration scenarios for providing services.
- Object-relational mapping, which should make persisted data easier to define and use in EMS applications. (Note: I believe Java SE 6 now supports the Java Persistence Architecture, which may mean we don’t need a Java EE application server for this functionality. I’m not entirely sure.)
- Web frameworks, which would provide various forms of client access (web services, web browsers, and rich clients).
- Security frameworks, which would provide uniform user authentication and authorization of privileges.
Of course, it is possible to get all of the above as individual components outside of a Java EE application server, but having a standard framework to tie it all together makes sense. Also, standards make it easier to find people who know the frameworks and can be productive quickly.
Overall, it is probably clear from my wording that I have a positive opinion of using Java EE as a basis for an EMS. But it requires further, careful exploration. I am in the process of learning about the JBoss application server, and I have also had some exposure to Sun’s Java EE application server. I will post more as I learn more about both.
Sunday, March 11, 2007: More on Creating an EMS on a Java EE App Server
It’s been a while since my last post. I never realized how difficult it is to find time to blog in the midst of daily life. I know that’s old news to you seasoned bloggers out there, and it makes me appreciate the amount of work that so many other bloggers and podcasters put into their material every day. Thanks to you all! But my gratitude aside, this post is meant to be a continuation of my last post: a status update on my thinking about using Java EE as the basis for an EMS.
Truthfully, I have not gotten much farther on this than I was 6 weeks ago or so. The only thing I’ve really learned since then is that Java EE is massive, and therefore it is very difficult to grasp in its entirety. Part of my issue is that I do not have substantial experience with it, other than using JBoss for a small web application. And truthfully, this web application could have just used Tomcat — it did not need the full functionality of JBoss at all.
But back to my learning. I’ve been reading JBoss At Work and going through the exercises, and my conclusion so far is that I still have a lot to learn, and will still have a lot to learn after I finally finish all the exercises. It makes me wonder: is there a better alternative with less of a learning curve? Or, is the learning curve worth the functionality obtained? Those questions are yet to be answered.
Those questions aside, I have still been developing my vision of what an EMS would look like on a Java EE application server. It would look something like this:
A key piece of this architecture is the Device Management Tier. This tier consists of one or more device management applications, which know how to configure and monitor a specific set of devices. If there is a need to support multiple types of devices (not unusual for an equipment vendor with an evolving product line), the management of different device types would be encapsulated into individual device management applications.
You may also notice Element Management Rules where you might usually see Business Rules. I don’t mean to exclude business rules, but I want to highlight the need for rules specific to element management. These rules would often be at a lower level than rules used to run a service provider’s business, but would also be at a higher level than flipping a bit on a device. Element Management rules might define, for example:
- Alarm severity levels
- Alarm correlation logic
- Subscriber service definitions (service type, quality of service, interconnection with outside providers)
- Backup/restore procedures for databases on managed devices
- Upgrade procedures for embedded software on managed devices
Of course, this list is not exhaustive.