Join / Log in
Learn how to increase the operational efficiency of the assets you manage, and improve overall equipment effectiveness by using IoT data and AI.
Reduce the operational costs of the facilities you manage, and create more engaging occupant experiences through the application of IoT data and AI.
Learn how IoT data and AI are being applied to transform the end-to-end engineering lifecycle.
That diagram is confusing IMO. The Maximo Object Framework (going to refer to as MBO, or Maximo Business Object beyond this) as they have labeled it should really be in-between the UI Framework & Maximo Database. They avoided the arrow going from the MBO to the UI framework which is important. MBOs don't really interact with the UI framework and the REST API does NOT utilize the legacy UI framework but at a glance it would look like it did. Whether you use classic UI or not, the MBO layer is always utilized and this is the layer interacting with the database primarily. The biggest reason to me behind this is becoming more stateless. Classic Maximo is a stateful application, meaning your session and everything you do in that session is tied to a specific JVM. As you are creating or modifying a record, those MBO(s) are stored in memory in that JVM. They've enhanced the REST API to really support this type of scenario where you can still have the benefits (such as filtered lookup values, immediate validation of the values, etc.) without actually needing to keep those MBOs in memory. Especially if your REST API was hosted in its own cluster, one of those JVMs could have handled your requests previously and go down and you wouldn't experience a disruption. Another reason is to develop a more modern interface. Most web developers utilize front end frameworks like React, Angular, or Vue to build web applications today. Trying to utilize those frameworks with the classic Maximo framework wouldn't be impossible, but would be a lot of work and you wouldn't be really taking advantage of those frameworks. As Biplap mentions this is currently Google Polymer today, but is being switched over to React.
Another reason why I like this is, and probably wasn't part of their decision point, is it really helps force a move of most of the logic that exists at the UI level before back into the MBO layer (or at least in processing classes on the object structures). There are many scenarios where something through the MIF functioned differently than something in the UI because the UI bean classes had additional logic in them. By utilizing the REST API for the new UI it should reduce the amount of times this occurs because you'll be able to write your integration using the same APIs as the work centers.