I’m wondering whether the Matterhorn architecture should push some of its cross-cutting concerns out to an ESB. Issues such as authentication, logging, auditing, etc could all be handled outside the container itself. This would imply that all service requests must be routed through the ESB.
In the OSGi context, clients would no longer connect directly to service implementations, even when they are deployed in the local container. They must always connect to service proxies, which route the service call out of the JVM, through the ESB, and back in through the service endpoint (REST or WSDL). The service proxy endpoints could be configured via the configuration admin service, or via context properties (e.g. config.properties).
The advantages include centralization of cross-cutting concerns, but all service requests would require marshalling/unmarshalling, or in other words would sacrifice runtime efficiency for centralized configuration / customization.
Comments Off
For the most part, I’ve been pretty happy with the distributed OSGi programming model. Unfortunately, there are a couple of areas where the reference implementation is getting under my skin:
- WSDLs are not easily usable outside DOSGI
- There is no obvious way to handle cross-cutting concerns
It may be possible to fix my WSDL gripe by modifying the CXF DOSGi implementation to use JAXB and JAX-WS annotations. This would make the WSDLs more usable, but there was quite a bit of disagreement on the CXF mailing list about the wisdom of annotating the service interfaces. Still, I might spend some time investigating whether this is a workable solution.
To handle cross-cutting concerns, I’m about to take a look at Equinox Aspects, but I’m hesitant to go down that path for two reasons. First, it seems to be designed specifically for the equinox container. And second, it is yet another pre-1.0 project, and I’m hesitant to keep building upon such bleeding-edge technologies.
Comments Off