Java web app integration with PeopleSoft - modularity evolution

A good chunk of my work over the last few years has involved producing Java web applications which work with PeopleSoft.  This post documents the basic module/jar breakdown that I tend to start with and some indication of changes to support future needs. 

The basic war/jars with sample descriptions breakdown like this:

The above works ok in general and has facilitated code sharing between multiple applications.  Some changes have occurred over time resulting in some benefits.  Originally, there were a few API's based on static methods - the most prominent being SQL utilities.  After getting the basic idea working, I converted it to interfaces and implementations.  The resulting benefits included an improvement in testability and multiple concurrent database type support [Oracle and HSQL mainly]. This should have been done using non-static methods initially but at least it was a straight forward conversion in the end.

There are still a few small static API's which make sense with the existing application designs and implementations.  These cover some string and date handling and such which work fine with static method implementations.  There are larger problems to solve instead of worrying about small static utilities.

The above describes a pretty good and time tested design.  There are drivers of change now though that are pushing me to newer and more flexible designs.  The drivers include:

• budget reductions
• lack of adequate staff
• excessively short development time frames
• integrations increasing in quantity and complexity
• increasingly higher application/feature availability

With that said, the general solutions I am pursuing to meet the needs now involve more web services, OSGi and various other messaging/integration technologies.

Now that I am working with OSGi, I am considering it for more general usage at the application level.  My initial plans involved evolutionary changes to existing systems but early prototyping found some issues with that.  I am finding that a number of previous decisions would need to be revisited for existing code bases. That isn't necessarily bad - some types of changes are likely more inline with current general best practices.  In any case where a major impedance mismatch occurs with OSGi; it may be time to reevaluate the implementation or feature. 

The issue with the largest scope so far seems to be due to bundling API interfaces with API implementation in the same jar file.  The OSGi way seems counter to this.  This does affect static API's but it also affects other non-static API's if you didn't plan ahead.  The "best" packaging appears to be separate jar files for API interface and implementations.

Currently, the most annoying issue tied to OSGi is related to the way I handled caching.  I wanted to use a "standard" caching API but JSR 107 was not released as final when I started my cache support.  I ended up using a snapshot of JSR 107 which worked wonderful in several non-OSGi applications.

The use of the snapshot along with some OSGi issues related to Infinispan dependencies resulted in some "irreconcilable differences".  I have yet to find a way to get it working without repackaging something with dummy version info and/or reworking some code.  For now I am putting this support on hold until I have time "to do it right".  There is a newer Infinispan out now which may help (or not) - will figure it out later.  This could be a good time to reevaluate the caching support; most of the caching support was done to handle the fact that in the past the ERP system could barely function normally and external apps/integrations had it near collapse at high utilization times.  Hardware has significantly improved and this hasn't been the case for some time with the ERP. 

Anyways, the expected plan is to start splitting out most existing functionality in OSGi compatible ways. Interfaces and implementations in separate jars and at a more fine grained functionality level. This should be pretty straight forward for large portions of existing code bases;  I suspect the 80/20 rule will apply in this.  I think the initial priority will be some of the utility code which will be useful with some new web services and other integrations.

God bless and Happy coding!
Scott

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.