What can you do to bring costs down and provide better value to the public/consumers?
In this case, I am evaluating replacing the commercial product with Apache ServiceMix.
My first impression is that there is a lot of value bundled with ServiceMix and the wide assortment of technologies it works with. The initial major downside appears to be a lack of equivalent tooling for handling the details of various DB trigger based integrations. The existing commercial tool is more technical-end-user / operations oriented than ServiceMix which is developer oriented. For this organization, this is a somewhat painful tradeoff but hopefully methods to reduce the pain will be found over time.
Other items to note include there is a general expectation that Maven is used; the ServiceMix examples involve its use. I decided to include Eclipse in the mix since a number of people will be involved in this and I am hoping that a GUI may help in the transition. I may regret the Eclipse / Maven integration; it has provided a few pain points in getting started. If there is a budget for more formal training, it would likely be very worthwhile.
Primary aspects of ServiceMix functionality I want to evaluate:
- OSGI and the impact on the development and operations processes
- CXF web service implementations
- Camel routes to tie some of the functionality together
- ActiveMQ for some internal messaging/high availability/reliability needs
- Activiti for performing some more complex workflows
OSGI is a lot of things but it all starts with modularity. In the case of ServiceMix, Karaf is the underlying core OSGi container. I am focusing on Karaf 2.4.0 (in ServiceMix 5.3.0) for now; it is a recent release which is sort of a bridge between major differences between 2.3.x and 3.0.x. It supports the OSGi R5 specification and has fairly recent dependencies. I am not convinced that we really need some of the features in R5+ right now but hopefully this version may ease any later upgrade we need to perform. There are some supporting technologies which I am looking into as well. The Apache Cave and Cellar projects are partly what drew me into taking a closer look. The Cave project is an OSGi bundle repository which I am still figuring out how it fits in compared to a plain Maven repository or repository manager such as Artifactory. The Cellar project is for clustering Karaf. This may be a good method of gaining scalability and availability in a production environment.
I have been prototyping a few things but decided to take a chance on a few books to see if they could provide a little extra insight or provide quicker/more clearly. The books in question are
- Enterprise OSGi in Action - Manning Publishing
- Learning Karaf Cellar - PACKT Publishing
- Learning Apache Karaf - PACKT Publishing
- Apache Karaf Cookbook - PACKT Publishing
I had picked up Enterprise OSGi in Action quite a while back and had skimmed it but had no time to really put it to use. I think it is a decent book and was my main initial exposure to much of the terminology. I do find that there are things that didn't become clearer until reading a few other books/resources.
I found Learning Karaf Cellar to be a reasonable book. It did clarify and confirm a few things I was wondering. It didn't answer all my questions but got me a little further than I was. One area of clarification includes the need/use of the cellar-eventadmin feature - in my prior testing I had installed it but the book seems to neglect it. Most of what I was really looking for (at the moment) was in the last 20 pages or so of the book.
The Learning Apache Karaf has a few items I did not know. There is overlap with the Cellar book but that isn't too terrible. Since I have been playing with Karaf for a bit over a month now some of the basic command info wasn't needed but if you were starting from nothing would be useful.
I'm just poking around the Cookbook for now. It tries to point out differences between Karaf 2.x and 3.0 but may be more 3.0 focused. Some of the items are interesting and I may try to evaluate or leverage. Will have to really read more in depth before commenting much more on it.
Between my research and prototyping, I am thinking that my desire to use the Distrubuted OSGi (DOSGi) enterprise functionality may be premature (with regard to remote services mainly). I think just clustering Karaf with Cellar and putting it behind a load balanced will likely provide most of what I am thinking of for an initial deployment. I also recognize that the default Cellar setup isn't fully capable of meeting my initial expectations - mainly by not persisting some settings/config to disk. The Cellar book discusses that aspect of their use of Hazelcast a bit which is nice but I will likely have to find some Hazelcast specific documentations to get the details I need. I am still trying to work out if/how declarative services should fit in to my plans (versus Spring or Blueprint).
Onto CXF; I have a service and client in prod using this but they are outside of any OSGi environment. I have prototyped a couple other services in OSGi with CXF and am very pleased with some aspects. One big plus is with PeopleSoft; I must be able to utilize multiple versions of the PeopleSoft provided API jars for accessing application servers. OSGi allows me to do that; allowing me to create services targetting multiple PeopleSoft instances with different PeopleTools versions and have those services deployed in the same process.
For Camel, I am still working on how to best utilize it. I think that creating a number of fine grained services in place of the few but beast like monolithic services is a better way to go. With those in place, I can use Camel to tie them together to match existing data flows. Combined with OSGi, there is a distinct dynamism which we don't currently have which hopefully speed up turn-around on changes.
I am still considering ActiveMQ for our environment. It is a touch call for whether the cost of potential lost transactions is higher than the implementation and operations cost of using ActiveMQ. I am really torn on this; it would probably benefit our users on likely rare occasions but would incur a cost to manage/maintain. Still an item of active consideration.
There are a few places where real workflow would just make a lot of sense and using appropriate tools likely will be a big benefit here versus just codifying it. That is the reason I would like to look into Activiti. It will not do much without changes to some of our applications and those are likely big changes. This is a longer term target.
Adopting something like this will have an effect on our development processes/environment, testing environments, production setups and deployment/maintenance methods. I'm planning on trying to document some of the details of processes and procedures I am going through during my research and planning.
God Bless!
Scott
No comments:
Post a Comment