Most Fusion Middleware products count by processor with core factors, the same metric as the database. The difficulty is not the math, it is which components are separately licensable, which ship under restricted use rights, and which options are in scope. Get the licensing basis of each component right and the count follows.
Fusion Middleware is where certifications get tangled, not because the processor math is hard but because the product family is layered. A single deployment of WebLogic Server can sit beneath several products, some separately licensable, some bundled, some carrying restricted use rights that only allow use alongside another product. A clean middleware count is mostly a matter of correctly classifying what is actually deployed and on what licensing basis, before any cores are counted. This article walks through how Fusion Middleware counts at a certification, the traps that distinguish it from a plain database count, and how to build a middleware number that survives review. As always, the specifics turn on the product list and the licensing terms in your own agreement.
Most Fusion Middleware products are counted by processor, with core factors applied to the cores running the software, the same metric used for Oracle Database. The base mechanic is therefore familiar: identify the cores, apply the relevant core factor, and arrive at a processor count. The complications sit on top of that math. They are which components are separately licensable, which carry restricted use rights, and which options are in scope, and those classifications drive the number far more than the arithmetic does. The wider set of middleware specific pitfalls is collected in middleware ULAs and their traps.
The Fusion Middleware family includes WebLogic Server in several editions, SOA Suite, Coherence, Service Bus, and a long list of related products and options. Many of them install together, and several can be present on a server without being separately deployed in a licensable sense. The first job is to classify each component into one of three buckets, because counting depends entirely on which bucket it falls in.
These are products that require their own license and therefore their own line in the certification. WebLogic Server Enterprise Edition and SOA Suite are typical examples. Each is counted by processor on the cores where it runs, and each appears as its own certified quantity. Missing one of these understates the count and creates exposure; double counting one overstates it.
Some components are included with a parent product and do not need separate licensing when used within that parent. Counting a bundled component as a separate licensable product inflates the number against a metric the contract does not require. The discipline is to confirm, for each component, whether it stands alone or is included, and to count only what genuinely requires a license.
This is the trap that catches the most careful teams. Several Fusion Middleware components, including some editions of WebLogic, ship with another Oracle product under restricted use rights that permit their use only with that product. Counting a restricted use component as if it were fully licensed is one error; using it beyond its restriction is another, and the second creates real exposure. Confirming the licensing basis of each component is the step that prevents both.
The restricted use trap is treating a component that came bundled under restricted terms as though it were a full use license. Some Fusion Middleware pieces are delivered with another Oracle product and may only be used in support of that product. If your deployment uses such a component standalone, or for a workload the restriction does not cover, the use is outside the grant and exposed in a review. Equally, certifying a restricted use component as a full use processor quantity claims an entitlement you do not need. The defense is to read the restricted use terms for every bundled component and count each on its true basis.
An indicative estate runs WebLogic Server Enterprise Edition across two clusters. Cluster A has 4 servers, each with 2 sockets of 8 cores, on a processor architecture with a 0.5 core factor. Cluster B has 2 servers of the same build. Cores in Cluster A total 4 × 2 × 8 = 64 cores; at a 0.5 core factor that is 32 processors. Cluster B totals 2 × 2 × 8 = 32 cores, or 16 processors. The WebLogic count is 48 processors. A separately deployed SOA Suite on Cluster B's 2 servers adds 16 processors on its own line. A management component bundled with WebLogic and used only within it adds nothing, because it is included. The figures are indicative; your core factor, editions, and the licensing basis of each component come from your own agreement and the applicable core factor table.
The method is classify first, count second, evidence throughout. Reversing the order is how the errors appear.
Discovery for middleware must reach component level, because a server list that records WebLogic but not the SOA Suite or Coherence running on it will miss licensable products. The inventory should capture what is installed, what is actually used, and how each component relates to the others, so the classification step has the data it needs.
For every component, establish whether it is separately licensable, included, or restricted use. This is the step that determines the number, and it is the step most often skipped. The licensing basis comes from the product definitions and the terms in your agreement, and where the answer is unclear it should be resolved before certification rather than assumed.
Once each separately licensable component is identified, apply core factors to the cores it runs on and record the working. The evidence file should show, for each product line, the servers, the cores, the core factor applied, and the resulting processor count, exactly as it would for the database. That documentation is what supports the number if it is ever reviewed, and the standard for it is the same across every product you certify.
An accurate middleware count often reveals that some products are barely used or carry restricted use complications that make certifying them poor value. At that point the question shifts from how to count to whether to certify each product at all, and that is a strategic call about the shape of the certified estate. The framework for making those product level decisions, including for Java alongside the middleware, is set out in our Java ULA material, and the parallel counting work for Java is in counting Java deployments at certification.
Fusion Middleware counts cleanly once each component is classified on its true licensing basis, so classify before you count, reach component level in discovery, and document the processor math for every product line. Start with middleware ULAs and their traps, run the parallel Java work in counting Java deployments at certification, and frame the exit through our ULA exit strategy guide. Because the licensing basis of each middleware component depends on your product list and terms, the count is only as reliable as the contract reading behind it.
Most Fusion Middleware products are counted by processor, with core factors applied to the cores running the software, the same metric used for the database. The complications are which components are separately licensable, which carry restricted use rights, and which options are in scope, not the base processor math.
Some Fusion Middleware components ship with another Oracle product under restricted use terms that only permit use with that product. Counting a restricted use component as if it were fully licensed, or using it beyond its restriction, both create errors, so the licensing basis of each component must be confirmed before counting.
We inventory your middleware to component level, confirm the licensing basis of each piece, and build a processor count you can defend, with the working documented line by line.