Configuring OpenAM Session Failover to run as a Windows Service

In hopes of saving people many hours of frustration I am documenting here what I did in order to get OpenAM session failover to run as a Windows Service rather than as a perl script (amsfo.pl). I did this so if/when the server restarts the session failover service will automatically restart. First, follow the instruction here - https://wikis.forgerock.org/confluence/display/openam/5+Extending+to+a+Dual+Instance+Deployment up to "Activating Session Failover". You will need to download and install Apache Commons Daemon, http://commons.apache.org/proper/commons-daemon/, and install/copy it to a directory where you want to reference it. Now the fun starts:

1. Rename procrun.exe to the name you want the service to run as, I used OAMSessionFailover.exe. (Note: you may need to copy the correct binary version from the subdirectory for 64 bit exes)
2. Rename prunsvc.exe to the name you want the service to run as, I used OAMSessionFailoverw.exe Note: no special binary version for 64 bit OSes)
3. Make sure that JAVA_HOME and JRE_HOME environment variable is set.
4. I found that using host names rather than virtual DNS entries works better for the cluster list
5. Configure/Install the Apache Commons Daemon service by doing the following (replace anything in italics with your values):
1. set SERVICE_NAME="OAMSessionFailover"
2. set "EXECUTABLE=C:/SessionFailover/bin/OAMSessionFailover.exe"
3. set "PR_DESCRIPTION=OpenAM Session Failover Services"
4. set "PR_INSTALL=%EXECUTABLE%"
5. set "PR_LOGPATH=C:/SessionFailover/logs"
6. set "JMQ_INSTALL_DIR=C:/OpenAM-10.0.0/tools/ssoSessionTools/jmq/imq"
7. set "PR_CLASSPATH=%JMQ_INSTALL_DIR%/lib/imq.jar;%JMQ_INSTALL_DIR%/lib/jms.jar C:/OpenAM-10.0.0/tools/ssoSessionTools/ext/je.jar;C:/OpenAM-10.0.0/tools/ssoSessionTools/locale;C:/OpenAM-10.0.0/tools/ssoSessionTools /lib/am_sessiondb.jar;."
8. set "PR_JVM=%JRE_HOME%\bin\server\jvm.dll"
9. set JAVA_CMD_OPTIONS=-a;cluster_list;-u;user_name;-f;passwordfile;-b;database_dir; AMSESSIONDB_ARGS;-m; C:/OpenAM-10.0.0/tools/ssoSessionTools/sfoscripts/config/lib/amsfo.conf
10. "%EXECUTABLE%" //IS//%SERVICE_NAME% --StartClass com.sun.identity.ha.jmqdb.client.FAMHaDB --Startup=auto --StartMethod=main --StartParams="%JAVA_CMD_OPTIONS%" --StartMode=jvm
6. . Configure the Message Broker Service by doing the following (replace anything in italics with your values):
1. set IMQSVCADMIN_OPTIONS=-name broker_instance_name -port broker_port -cluster cluster_list
2. %JMQ_INSTALL_DIR%\bin\imqsvcadmin.exe install -vmargs "-Xms256m -Xmx512m" -args "%IMQSVCADMIN_OPTIONS%"
3. The message queue must start before the session failover service so do the following to tell Windows that the dependency exists:
1. sc config OAMSessionFailover depend= Tcpip/Afd/MQ4.4_Broker
7. Start the services
1. sc start MQ4.4_Broker
2. sc start OAMSessionFailover
8. Configure OpenAM to use session failover
1. set FAILOVER_CONF_FILE="session-failover-subconfig-attributes.txt"
2. >%FAILOVER_CONF_FILE% (
3. echo iplanet-am-session-jdbc-url=cluster list(host:7777,host2:7777)
4. echo iplanet-am-session-sfo-enabled=true
5. echo iplanet-am-session-store-cpl-max-wait-time=5000
6. echo iplanet-am-session-store-password=password
7. echo iplanet-am-session-store-username=user
8. )
10. ssoadm create-sub-cfg --servicename iPlanetAMSessionService --subconfigname sitename --subconfigid Site --priority 0 -D "%FAILOVER_CONF_FILE%" –u amadmin –f passwordfile.txt (Make sure subconfigname is you site name – it must match exact!!)
9. This does not shutdown the process cleanly because there is no way to get to the private method that shuts down the session db (Unless you wite a hack class that makes the method public and call it that is! :)

I hope this helps someone!

Technical debt was first defined by Ward Cunningham as:

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise." - Wikipedia

I think Ward had it right, like that's a big surprise. Technical debt is like taking a loan out from a loan shark. You borrow at high rates and hopefully for a very short time. If you don't pay it back quickly you will end up paying a lot more over time. Making small payments on the debt will help but until you get it down to a very small sum, or zero, you have the issue of compunding interest.

What this means for solution development is that every time you take that short cut in the name of saving time, make a design decision that is "not the way it should be done", or not keeping vital documentation up-to-date you are incurring technical debt. All of these choices make the system more fragile, less maintainable, and more costly to run. This debt burdens a system until it is repaid. In some cases the debt becomes so high that the application is declared bankrupt and it is liquidated, that is it is replaced.

It does not take a lot of technical debt to start the bankruptcy process. When code becomes too fragile, the design too complicated, or too little documentation for the decision to be made to replace a solution rather than fixing it. A small amount of technical debt on even a single piece of code can lead a developer to not want to alter it because they don't understand it or are afraid of what the changes might do. This leads to "work arounds" such as creating new code for the specific condition the developer needs to deal with. This is typically implemented with some type of "if...then" block of code. Now we have two pieces of code that do practically the same thing. This makes the system even less maintainable and increases the technical debt.

The best way to deal with technical debt is recognize that it exists, track it, fix it, and then figure out how to fix the process so it doesn't happen again. This is a typical Six Sigma approach to quality issues. If a team tracks the decisions that lead to technical debt you not only track that it is out there but also give them the tools they will need to analyze how to prevent it in the future.

Make sure that you point out to management and your customers that you made some decisions during implementation that sere sub-optimal. Make them aware that not repaying the debt will lead to even higher balances int he future and a fragile system. This has to be expressed in business terms such as business lost productivity, unplanned outages, and increased support costs to name a few. If you can't convince them of the urgency of repaying the debt keep the list of technical debt around. Sooner or later they will come back to you and talk about a problem that you can directly relate back to the technical debt that you have on your list. this is an excellent opportunity to politely bring up the topic of technical debt again. Sometimes we don't succeed the first time we talk to them about technical debt but sooner or later you will get through!

Incremental vs. Iterative Development

I have been in several discussions lately about iterative versus incremental development and there has been a lot of confusion about what each means. I wanted to give my two cents on what I think the differences between the two are.

Incremental development to me is the process of building a whole piece of the solution to its completion and then moving on to the next piece. An analogy that I have used is the building of a house. Using an incremental approach you would build out all of the first floor, including the electrical, plumbing, dry wall, carpeting, etc. before starting anything on the second floor. This way you know that the first floor is complete and ready for the occupants to move in. In software development this would mean completing a subsystem, or a portion of the application, before you start the other subsystems or portions of the application.

Iterative development to me means building a business flow, with the minimum of functionality even, from start to end before adding more features, nice to haves, etc. Using the house analogy you would construct all the framing for a house before you added electrical, plumbing, etc. This way you are sure that all of the framing is solid and the rooms are laid out correctly before you start on the next feature/service.

Incremental and iterative development can co-exist in software development. You could complete one business process with minimal functionality quickly and then start on other business processes. Then you would start working on filling out the functionality of a business process iteratively. This would be incremental and iterative at the same time.

I prefer iterative development because I believe that showing business partners a minimally functioning solution before building out all the functionality gives them the opportunity to change the implementation before it is too costly to make the change. It also means that the business can make a decision that a feature may not be worth the development effort and launch without it.

Cloud Computing Buzz

There is a lot of buzz about Cloud computing lately that I think is misleading. Like all new IT silver bullets the advertising machines from vendors have been whipped up to a feverish pitch. They are selling all types of IT snake oil silver solutions and telling CIOs that if they don't have applications in the Cloud soon then they are behind the times and will be replaced soon.

First let me define what I mean by Cloud computing. I define Cloud computing as an externally hosted platform for running applications. This definition has also been known as Platform-as-a-Service or PaaS. Examples include Amazon's EC2 and Google's App Engine. There are many more out there but Amazon and Google are two well known providers. Others have defined Cloud computing as anything that doesn't run in your data center. This would include things like Google Docs, GMail, and the like. I think this is a stretch of the definition of Cloud computing since these are pre-defined applications that have a single purpose. Cloud computing is more general purpose than this definition.

I believe that Cloud computing has a place in the future of some companies. Companies that do not have the cash or people to put a data center together can get huge benefits from cloud computing. The ability to make infrastructure available quickly and inexpensively, initially at least, is exciting. There are several scenarios that companies can use this kind of infrastructure including proof of concept work, development environment, or even self contained applications.

I have an issue with the assumption that Cloud computing is a cure all for all IT problems. The Cloud does not solve the issues of integrating data from legacy systems, which now maybe defined as anything not running in the Cloud, development issues that arise from programming for a new environment, and even requirements issues. These problems will exist no matter where the solution is hosted. There are new issues that exist with hosting an application in the Cloud. Different national privacy laws, getting data out of the Cloud, and service availability are just a few issues that come off the top of my head. These all have far reaching affects on the suitability of Cloud computing for a company.

So if you are looking for a fast and efficient way to get infrastructure up and running then definitively look at cloud computing. But go in with your open. Have experienced IT people ask the hard questions about how the service works and how it will fit into your environment. Look at the cost of not only the infrastructure but the cost of developing and integrating the Cloud environment into your application portfolio.

Just my thoughts.

Tony

Agile Zealots

There are way too many people out in the agile community who claim to be agile experts who will tell you that you are not doing Agile right if you don't do this practice or that practice. They will tell you that if you're not doing Test Driven Development (TDD), paired programming, daily stand ups, etc. that you're not Agile. Who anointed these people and made them the deciders of what is and isn't agile? As far as I've seen the agile manifesto (www.agilemanifesto.org) only states that there are things that agilists find more valuable than others but says nothing about what things make up a true implementation of Agile.

Each group that has decided to go agile has to decide what practices it will start with. I encourage them to start small and build out for a core competency. Start with a daily stand up and small iterations. Maybe use user stories too. But start slowly, gain momentum, and learn as you go. Building from a solid base is better than starting with everything, also known as boiling the ocean, will lead to more confusion and distractions than it's worth. At the company that I learned Agile at we started with a iterations, user stories, backlog, and role definitions. We then went on to do some XP practices after some time. It was still hard to get right but if we'd started with everything we'd have overwhelmed everyone and have gotten less return on our investment.

So if you're new to Agile, don't let anyone tell you you aren't doing Agile right. If you hear that from someone, even one of the leader in the the Agile community, ask them where the definition of what practices you have to do to be Agile is written down. I've never had someone be able to show me where it is. Agile is adaptive and purposely is not defined. You need to define what practices you need for your organization. Some practices may make your implementation of Agile more successful but there's no wrong answer when it comes to what Agile is.

Just my two cents.