OOW2011 : OBIEE 11g Architecture & Internals
I've just finished my first session of Oracle Openworld 2011, on OBIEE 11g Architecture and Internals for IOUG's BIWA SIG. Thanks to everyone who came along, and I hope it was a useful session.
The slides for this session are available here : OBIEE 11g Architecture & Internals
Product internals are always an interesting area for me, and you've got a lot to go on in OBIEE 11g as there's just so much middleware, servers, metadata and other elements to go on. One of the most useful parts I think of the whole session is going through the high-level logical architecture of the product.
In OBIEE 11.1.1.5, the "regular" installation method is called the Enterprise Install, and gives you a logical architecture that looks like the diagram below:
The basic unit of organization for an OBIEE 11g system is called an Oracle BI Domain. An Oracle BI Domain consists of Java, and non-Java components, with the Java components being organized into a single WebLogic Domain. Over time, you can scale-out this WebLogic domain to include additional managed servers on additional hosts, though you need to purchase the additional WebLogic Server Enterprise Edition to make use of this.
The 11.1.1.5 release of OBIEE also introduced a new install type, the "Simple Install", which did away with the managed server, along with the Node Manager server, reducing the memory footprint of the installation but at the cost of future expandability.
The WebLogic domain, for an Enterprise Install, initially consists of a single Administration Server and Managed Server, with the Administration Server containing the WebLogic Administration Console, Oracle Enterprise Manager and Java MBeans applications, and the Managed Server containing all the OBIEE Java components such as BI Publisher, the Action Service, the BI Middleware application and the BI Office application.
What we know of as the BI Server, BI Presentation Server and other "traditional" OBIEE server components are referred to collectively as System Components, and are installed, alongside the Java components, on each host. Within each host, each set of system components are collectively known as an Instance, with each instance being managed by its own installation of OPMN, or Oracle Process Manager and Notification Server. OPMN controls and monitors the various system components within it's instance. When you scale-out an OBIEE system over several hosts, you can end-up with several instances, once for each host.
Collectively, these instances together are known as a Farm, and the farm is what Enterprise Manager manages when you log in and make configuration changes.
The other topic, in terms of internals, that I covered in the session was around the Oracle BI Systems Management API. I'll cover this in more detail in my presentation on OBIEE Systems Management on Thursday, but understanding the Systems Management API, the MBeans that make them available, and how Enterprise Manager uses these under the covers is to me, the key to understanding how OBIEE 11g works under the covers. I'll cover these in more detail on my write-up on Thursday's presentation, which covers this topic in-depth.