Apache ServiceMix - intial thoughts

So you have a really expensive (purchase price) integration product which has ridiculously high yearly maintenance fees in a public service type organization which isn't out to make money.

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

I'm not an expect (yet!) in any of these but I have been slowly starting to work myself through the details.  I've been spending a little time over the last month or so getting a better grasp of the technology and if/how it may fit into our needs. Below is just my brief overview - I am planning to more in-depth posts as time permits.

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

Sort of funny but I am reading them in the above order.

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

FIM R2, Active Directory and the Password Change Notification System - success

Ok, so a project ends up defined different from my expectations and now I need to sync passwords between Active Directory and some external systems where one of the targets is an Oracle database.  After a bit of thought, I decided that the best solution to this was to utilize our FIM R2 environment and implement the MS Password Change Notification Service (PCNS).

This solution is somewhat complicated by the fact that my Windows programming skills are a bit rusty; mostly ending at around MS Visual Studio 6 and prior to having to work with .Net.  At the time, I worked with C/C++ in the Windows environment and C/C++ in several Unix environments as well.  Most of my recent experience is Java.  I decided early on that this solution should use C# to fit in with some existing integrations implemented originally by MS FIM consultants.  The good news is that we had an appropriate version of Visual Studio available and installed where I could use it.  The downside was that after our spring upgrade to FIM R2, I had not taken the time to setup Subversion source control integrations in Visual Studio. 

So before starting any development work; I wanted to make sure I could version control the new stuff.  I had an existing repository for the existing integrations which was good.  I couldn't remember which Subversion Visual Studio integration we used originally but I knew I didn't want to try and use anything requiring a purchase or a license incompatible with our needs.  I ended up using AnkhSVN (which was probably what I did in our original FIM environment).  It was an easy install and compatible license wise.

With my source control prerequisite out of the way; I took a look at some coding resources that a co-worker had found.  One of the resources had some notes, documentation and a code sample/template (found here).  This looked pretty straight forward; so I jumped into the work.

First I needed to create a solution/project; I needed a DLL in this case which is one of the types available.  I renamed the initial c# source file I created to match my intent a bit more.  I was able to add the solution to Subversion pretty easily and tested the check-in of changes in the project to verify it was working ok.  Next, I copied in the template code and then started modifying to our needs.  Some changes I had to make involved externalizing the DB connection info.  I was able to pull some code from a different integration which accessed an XML configuration file for some settings.  I was then able to copy and modify that code to access more appropriate tags containing my DB connection info.  After making a quick copy of the XML configuration file from the other integration and tweaking it to match the expected tag names and connection info; my configuration needs were pretty much done.  After this; I updated the SQL statement per our environment needs. 

At this point; the code was in place but it was not able to compile.  I still had to add some missing assembly references.  Fortunately, with a little trial and error I was able to identify the required assemblies and they were visible in the dialog so I didn't have to go researching where to acquire them or register them, etc. 

Once I got it compiling; there were 2 other items which I identified as needing attention.  I needed to update the project to produce a 64bit artifact and I needed to set the .Net framework to 4.0 to match the existing FIM integrations.

At this point; I had what was a clean but untested build.  I did not have any type of test harness for this so a couple of co-workers setup the AD side of things and performed the FIM side setup which required this DLL.  You have to make sure the DLL is in a particular location for it to be visible in the FIM configuration screen.

Anyways, to make a long story shorter.. after a couple false starts in the FIM/PCNS setup we finally had all the pieces in place and were able to see it work.  A test utility which made password changes against AD was used and we were able to see the effect of the password changes in the destination DB.

There are still some test cases we need to verify because of user on-boarding workflow but the technology is working as expected.  Next, we have some ERP systems to update as well and the basic PCNS work will support that as well.  We will be working these solutions through our test environment on their way to production which should be in the next 4-5 months. 

I do have a few final thoughts on this part of the project.  I am very happy that the technology is working for us.  I do wish that I had a good method for out-of-system testing - hopefully time will permits it as we continue through our test/release process.  As in Java, there are a number of logging libraries for .Net from what I can tell.  In this project, I ended up with the same logging setup as used by our other integrations but the use and setup was not documented [anywhere I have found] by our past consultants.  I feel a bit like I bumbled along with some of this work.  Since we are likely to continue investing in FIM, I'll probably purchase some C#/.Net related books so I can feel a little more comfortable with those technologies.

[Update 2014/12/05] We started to set this up in our test environment but ran into issues.  As it turns out, there are some patch level differences between our FIM environments.  It looks like we need to
update out environments to at least the minimum level of our dev environment which appears to be a unreleased private build from Microsoft.  I suspect our MS guy had used a version available to him which fixed an issue at the time we were working on some other stuff.  We have yet to push some new stuff through the test environment and into prod so we hadn't noticed the difference until now.  There are a few recent public patches so we will likely level-set ourselves to one of those in dev and retest before moving the FIM updates to test and prod.  Wasn't planning on this - never  a dull moment.

About Me - work & goals

 My view of employment

• Work is a gift from God.  I feel too many people treat it as a curse.
• I believe in doing the best I possibly can; even if it isn't something enjoyable at various times.
• I believe that my work should benefit my employer.
• To excel at what I do requires continuous learning; 
• books, research papers, prototyping, self-learning, organizations like the ACM, Google and software related sites are required resources both during work and outside of work to gain and maintain skills
• Learning from others is wise; only relying on other peers is laziness.  You cannot improve at something without actually spending your time doing the work. 
• Don't just give up when problems get difficult; brainstorm with others, research alternative solutions, redefine the problem to provide a way to a different solution space, rethink the box.
• Work ethic is important to me; don't cut corners simply to take the easy way out.  If an employer requires cutting corners; make the implications known and either do your best or find an employer with compatible work ethics depending on the circumstances.
• Admit mistakes, learn from them and move on.  
• Remember to treat others as I want to be treated; abrasive personalities make this difficult but do the best to readjust self-attitude before making comments which cannot be taken back.
• Help others in need whenever possible.
• A sense of humor can help everyone during stressful time
• I should provide an honest assessment of both things that I can do and things that I am  not (overly) familiar with.  If you don't know something say so; even if you plan to figure it out.
• I should provide as realistic estimates as possible; yes a fudge factor for the unknown may be warranted.  If an organization has little/no emphasis on managing overall employee workload and the project on-boarding is a high-speed ramp then estimations probably have little value though.

My personal hope and expectations of an employer

• Respect for me and my family. 
• Respect for employees as a whole.  Actions speak much louder than words.
• Appropriate support so I may fully perform my duties to the best of my abilities 
• Reasonably clear and attainable goals
• Long hours on occasion are an expected part of the job; normal planning using 45+ hour weeks is not respectful of anyone or their families IF not stated during interviews and paid appropriately for the overtime.  In an interview, stating "occasional overtime required" but expecting normal 42+ hour weeks is deceitful.  I expect an honest assessment of the organizations needs. 
• Pay which matches industry expectations for the job function and area.
• The ability to use annual leave without a guilt trip.  i.e. having 6 months out of the year which are "too busy to use leave" is not very respectful unless it is made clear during interviews. 
• A day off should not have the normal meaning/expectation of "work from home".
• I expect managers not to use fear and intimidation as management tactics.

Hope this provides some insight into me for anyone interested.

For any readers of this that are interested in some of the biblical backing, here are some references from the New American Standard Bible of things I try to live by (but fail at all to often).

• Colossians 3:23 - Whatever you do, do your work heartily, as for the Lord rather than for men.
• Proverbs 14:23 - In all labor there is profit, but mere talk  leads only to poverty.
• Acts 20:35 - In everything I showed you that by working hard in this manner you must help the weak and remember the words of the Lord Jesus , that He Himself said, 'It is more blessed to give than to receive.'
• 1 Peter 4:10-11 - As each one has received a special gift, employ it in serving one another as good stewards of the manifold grace of God.
• 1 Timothy 5:8 - But if anyone does not provide for his own, and especially for those of his household, he has denied the faith and is worse than an unbeliever.