Reason # 4 JBoss Microcontainer
JBoss Microcontainer (MC) is at the core of JBoss AS and provides many essential services needed in developing any enterprise software application. Teiid utilizes MC, through several of its key sub-frameworks, to manage services and configuration/deployment artifacts.
Service Framework:
Prior releases of Teiid defined their own service framework(s). These legacy frameworks each had essential flaws - such as not being flexible in defining new services, not providing dependency management, or cumbersome/non-existent configuration management. Teiid in the 6.x releases used "google-guice" for dependency management between services with homegrown configuration management. The service lifecycle was explicitly managed through admin api methods.
MC provides a POJO based service framework with IOC style dependency injection and full lifecycle management. A simple XML based configuration can your POJO based services along with their state and dependencies. As an added bonus this framework also provides persistence services for the configuration. By moving Teiid to MC, we simplified the definition of our services and greatly improved our dependency management - which eliminated the need for Teiid specific configuration framework. Find more information on MC's component model here. And since MC also supports osgi and google-guice, integration of components developed against other IOC frameworks will work together seemlessly.
Deployer Framework:
Teiid requires deployment facilities to handle artifacts such as VDBs, Connectors/RARs, or connector bindings. In prior releases of Teiid deployment and discovery of deployed artifacts was homegrown and based upon different modes of operation - server vs. embedded. This led to inconsistenties in the deployment/discovery code. Dynamic class path management was also led to quite a few issues when JAR resources involved.
MC has the one of the best deployment frameworks with every flexibility you can imagine. As soon as an artifact is visible at a specific location, the deployer service gets notified. This removes the need to write any scanners for detection of artifacts for your application. This framework gives access to the input stream of the resource(s) that are deployed to be consumed by your service. If you are working with JAR or ZIP based resources, the deployment can be defined to check the structure and validity of the resource.
The MC framework provides resources through a Virtual File System (VFS) such that you can replace standard file based deployment with any structured repository if you choose to. With the deployer framework you can also construct a class loader based on the artifact deployed. JBoss AS uses this feature to define WAR class loaders. You can read about class loading here. Teiid was re-written to use this deployer framework to load its VDBs (and any contained UDFs). Connectors were re-written as JCA connectors, which are deployed in JBoss AS using RAR and "-ds.xml" files that already have hooks in the deployment framework.
Management Framework:
Now that we have defined the services and deployed artifacts, how do you manage them during runtime? Teiid in the previous releases exposed specific administrative interfaces for management of certain resource and did not provide any JMX based management. This led to building Teiid specific Management Consoles that worked only with our administrative functionality. Integration into tools such as BMC patrol, HP Open View etc. for the purposes of management was not possible. For Teiid this was one of the *major* reasons to adopt MC.
MC provides a framework to define management interface on your beans through annotations. There is no need to define a MBean interface, yet it works like JMX 2.0 and has more features. JBoss also provides away to expose a JMX interface on your beans simply a providing the @JMX annotation - however this still requires you to define an interface. Teiid has not made use of this JMX feature, but will in subsequent releases.
One thing missing from MC was way to expose the management of your managed beans to external applications. However, JBoss AS luckily comes to rescue by providing the "profile service" through which these beans are exposed. The profile service lets you build your management applications using JOPR based tools. I think development is under way to pull the profile service technology into MC proper in the next release.
Conclusion:
Teiid used MC facilities to re-write its whole management layer. There is simply no comparing the ease with which our services are wired together, configured, and managed with our previous releases. This has created a strong dependency on MC and additional dependencies on JBoss AS. Hopefully this article did a good job highlighting all the benefits of the MC integration. Let's explore the JBoss AS dependency benefits in the next article.
JBoss Microcontainer (MC) is at the core of JBoss AS and provides many essential services needed in developing any enterprise software application. Teiid utilizes MC, through several of its key sub-frameworks, to manage services and configuration/deployment artifacts.
Service Framework:
Prior releases of Teiid defined their own service framework(s). These legacy frameworks each had essential flaws - such as not being flexible in defining new services, not providing dependency management, or cumbersome/non-existent configuration management. Teiid in the 6.x releases used "google-guice" for dependency management between services with homegrown configuration management. The service lifecycle was explicitly managed through admin api methods.
MC provides a POJO based service framework with IOC style dependency injection and full lifecycle management. A simple XML based configuration can your POJO based services along with their state and dependencies. As an added bonus this framework also provides persistence services for the configuration. By moving Teiid to MC, we simplified the definition of our services and greatly improved our dependency management - which eliminated the need for Teiid specific configuration framework. Find more information on MC's component model here. And since MC also supports osgi and google-guice, integration of components developed against other IOC frameworks will work together seemlessly.
Deployer Framework:
Teiid requires deployment facilities to handle artifacts such as VDBs, Connectors/RARs, or connector bindings. In prior releases of Teiid deployment and discovery of deployed artifacts was homegrown and based upon different modes of operation - server vs. embedded. This led to inconsistenties in the deployment/discovery code. Dynamic class path management was also led to quite a few issues when JAR resources involved.
MC has the one of the best deployment frameworks with every flexibility you can imagine. As soon as an artifact is visible at a specific location, the deployer service gets notified. This removes the need to write any scanners for detection of artifacts for your application. This framework gives access to the input stream of the resource(s) that are deployed to be consumed by your service. If you are working with JAR or ZIP based resources, the deployment can be defined to check the structure and validity of the resource.
The MC framework provides resources through a Virtual File System (VFS) such that you can replace standard file based deployment with any structured repository if you choose to. With the deployer framework you can also construct a class loader based on the artifact deployed. JBoss AS uses this feature to define WAR class loaders. You can read about class loading here. Teiid was re-written to use this deployer framework to load its VDBs (and any contained UDFs). Connectors were re-written as JCA connectors, which are deployed in JBoss AS using RAR and "-ds.xml" files that already have hooks in the deployment framework.
Management Framework:
Now that we have defined the services and deployed artifacts, how do you manage them during runtime? Teiid in the previous releases exposed specific administrative interfaces for management of certain resource and did not provide any JMX based management. This led to building Teiid specific Management Consoles that worked only with our administrative functionality. Integration into tools such as BMC patrol, HP Open View etc. for the purposes of management was not possible. For Teiid this was one of the *major* reasons to adopt MC.
MC provides a framework to define management interface on your beans through annotations. There is no need to define a MBean interface, yet it works like JMX 2.0 and has more features. JBoss also provides away to expose a JMX interface on your beans simply a providing the @JMX annotation - however this still requires you to define an interface. Teiid has not made use of this JMX feature, but will in subsequent releases.
One thing missing from MC was way to expose the management of your managed beans to external applications. However, JBoss AS luckily comes to rescue by providing the "profile service" through which these beans are exposed. The profile service lets you build your management applications using JOPR based tools. I think development is under way to pull the profile service technology into MC proper in the next release.
Conclusion:
Teiid used MC facilities to re-write its whole management layer. There is simply no comparing the ease with which our services are wired together, configured, and managed with our previous releases. This has created a strong dependency on MC and additional dependencies on JBoss AS. Hopefully this article did a good job highlighting all the benefits of the MC integration. Let's explore the JBoss AS dependency benefits in the next article.
Comments
Post a Comment