As most of you know, the current 11g version of the Oracle Identity Management Suite runs on top of a tech stack based on WebLogic Server. In essence, when you install any package from the 11g Identity Management Suite, you end up deploying the applications from the package into a WLS domain.
There are 2 basic models of domain architecture for the Oracle IAM suite:
1) Install a given package into a new, self contained, WLS domain.
2) Extend an existing domain. In other words, deploy the apps from the Identity Management package you are installing into a domain that is also running other software. This model includes several variations based on what else you are running in the domain. One variation is installing the different Identity Management suite packages (namely the Identity Management package containing OID, OVD, and OIF; and the Identity and Access Management package containing OAM, OIM, and OAAM) into one domain. Another variation would be installing one of the Identity Management Suite packages into a domain running another Oracle product such as WebCenter or SOA Suite. Finally, one might even consider installing an Identity Management Suite package into a domain running custom application code.
Basic coverage of the topic can be found in the documentation here: http://download.oracle.com/docs/cd/E14571_01/install.1111/e12002/extend.htm
My Advice
It might seem like one or more of the scenarios listed above in the “extend an existing domain model “option above would make life simpler. In particular, I think that many people who use the entire Oracle Identity Management suite might be tempted to create a single monolithic “IAM domain” containing both major packages such that (OID,OVD,OIF,OAM,OAAM, and OIM) would all run in the same domain.
However, I’m here to tell you that running multiple packages in one domain is most likely a bad way to go. The reason is that it introduces the risk that different components (libraries, jars, utilities) from the different packages that you are installing in the domain might be incompatible and cause problems across your entire domain.
I actually had this happen when I accidently installed the IAM package (OAM) into a domain that was only running the PS1 version (instead of the PS2 version) of the IM package (OID and OVD). The IAM package is only certified to run in the same domain as the PS2 version of the IM package and sure enough many things in the domain broke.
To make matters worse, there is little you can do outside of restoring a previous full OS backup to fix the situation if such an incompatibility occurs.
Beyond the risk of such an incompatibility, you also must consider how installing multiple packages into one domain reduces your flexibility to apply patches and upgrades. Let’s say a new patch set of the Identity Management package (OID and OVD) comes out. If you have installed the package into its own domain then you are good to go. However, if you have installed it into a domain with WebCenter or OAM/OIM then you must consider whether the patch set will be compatible with those other packages. So, you’ll have to open a support case to ask and if the answer is no then you might have to wait months for those other packages to catch up.
One exception to this warning is SOA Suite for OIM. SOA Suite is a prerequisite for OIM and as part of the stack that supports OIM should be installed in the same domain as OIM. However, if you use SOA suite for other purposes, you should consider setting up a separate install for running your own services, composites, BPEL processes etc.
Conclusion
While installing multiple Identity Management packages (or Fusion Middleware packages in general) into one domain might seem like a good idea as it gives you just less domains to manage, it is safer and better to install each Identity Management package into a separate, isolated domain.
To be clear, I am recommending that customers install the IAM package (OAM,OIM,OAAM) into a separate domain from the IDM package (OID,OVD,OIF). I am not necessarily recommending that you install the various products inside of each package in separate domains. If and when to do that is a topic for another discussion which I will try and post about soon.
Wednesday, January 12, 2011
Subscribe to:
Post Comments (Atom)
Posts
Brian,
ReplyDeleteBy package do you mean splitting the IAM stack (OAM/OIM/OAAM) from the IDM stack (OID/OVD) or each individual product in its own Domain?
Eric
Eric,
ReplyDeleteYes, I mean splitting the IAM stack (OAM/OIM/OAAM) from the IDM stack (OID/OVD).
Now, splitting up the individual products within a package into seperate domains is sometimes a good idea as well. For instance, people often install OIF into a different domain from OID and OVD. This is often done because OIF is seen as an "external" facing application where as OID and OVD are often seen as purely "internal".
The one thing to watch out for when splitting up the products in one package is that some of the interoperabilities between these products depend on them being in the same domain. The integration between OAM and OIM is one example.
Good question, I should probably write a follow-up post.
Great post.
ReplyDeleteIn Production systems, it would be great if we split these components deploying them in seperate servers based on IDM and IAM Stack. It is easier to investigate if any problems occur in this way.
Thanks for the post Brian, very informative! I'm a newbie to IDM - career DBA - and I'm curious about "BP" for installation. Would you separate the SOA and BI Publisher as well? Would you recommend only using the the SOA and BIPub products for IDM or could I point my existing apps at BIPub and take advantage of the capabilities rather than having another install base out there? Also, would you recommend renaming the installation homes? I'm playing with renaming my OIM "app server" install directory to Oracle_OIM1 instead of the typical Oracle_IDM1, rename OID from Oracle_IDM1 to Oracle_OID1, etc. Thanks again and I appreciate your feedback!!
ReplyDeleteRichard,
ReplyDeleteThe SOA Suite used by OIM must be installed in the same domain as OIM. That being said, I recommend that people use another installation of SOA Suite for non-OIM purposes.
I'm not sure about BI Publisher but I think the same advice would follow. Also, I'm not in sales but if you decide to use the BIPub that comes with OIM for other purposes be sure you have licenses that allow you to use it for other purposes.
Finally, I'd be reluctant to rename the install directory (though I do agree with the naming conventions you want to change to). I'd be pretty worried about the original location being written to all sorts of various files. I'd say wait until next time to go with your new names.
Good luck,
Brian
Thanks for the feedback Brian, Let me clarify the BI Publisher question a bit. Can I install it on a separate server (virtual environment, in our case)? In the future, once I clear up the licensing issues, I want to use it for more than IDM. I don't think I want to put it in the same environment as IDM. I want to isolate them from each other. Would that make sense?
ReplyDeleteBummer about the renaming... I've done it in my sandbox environment... fortunately I haven't gone any further :-)
I'm getting the hang of this... slowly but surely.. Thanks again!
Yes, you should be able to install BI publisher in a separate environment.
ReplyDeleteAs for the renaming, maybe I'm being overly cautious. If it seems to work in your sandbox and you've tested it extensively then maybe it is OK.
Hi Brian,
ReplyDeleteAlready I have a SOA 11g installed and working for other things. Is it possible to use that SOA for OIM 11g that I am going to install now?? I read that both things have to be in same domain. But is this scenario possible??
Thanks & Regards,
vasu
Yes, it is possible. In fact, installing SOA is a pre-requisite for OIM 11g today and they do have to be in the same domain.
ReplyDeleteThat being said, they also have to be at the same release level (ie 11.1.1.3).
I also recommend that if you are using SOA suite on its own, seperate from OIM, that you install a seperate instance of SOA suite on a seperate domain for the seperate usage.
Hi Brian, thanks for this informative blog.
ReplyDeleteI'm facing an issue related to upgrade and downgrade of SOA 11g.
I'd installed IAM package 11.1.1.3.0. Had configured OAM. Later in the same middleware home, thought of configuring OIM. With OIM, I needed SOA. Hence installed SOA 11.1.1.4.0, created schema using RCU 11.1.1.4.0. Now the issue I faced here was SOA 11.1.1.4.0 is not compatible with OIM 11.1.1.3.0(which I came to know later), hence had to uninstall SOA and install SOA 11.1.1.3.0 and create schema using RCU 11.1.1.3.3. Now while configuring domain for OIM, am facing JDBC connection issue for OWSM MDS schema. Connection is established but no rows are retrieved.
If I want to reinstall OIM, I cannot do it in the same middleware home, because that would override the OAM configuration. So can I create new middleware home for OIM alone and can OAM and OIM in different domains be integrated if required??
Thanks,
Moin
Moin,
ReplyDeleteI feel your pain. One thing I worry about is whether or not SOA 11.1.1.4 uninstalled cleanly or if there are still some 11.1.1.4 libraries floating around your FMW home that could be incompatible with IAM 11.1.1.3.
That being said, on the topic of OAM and OIM in separate domains, the documentation says they need to be in the same domain.
However, I have heard that this is due to the fact that the step-by-step instructions rely on the domain agent to protect the self service pages of OIM and that if you are using a real webgate/agent to protect the OIM self service pages that OIM and OAM can then be in separate domains.
Keep in mind though that I have not tried this myself and the official support for OIM/OAM integration with them in separate domains is ambiguous.
Another option might be to try and push through and resolve your OIM/schema problems.