The OMG, after realizing that this diverging of the BOA was becoming a problem, requested proposals for either enhancing the BOA or devising a new type of Object Adapter that would correct the problems encountered using the BOA.
The result of that request is the new Portable Object Adapter (POA), which has been adopted as the Object Adapter in the CORBA specification. The POA actually deprecates the BOA and is intended to completely replace the BOA in time, but vendors are free to maintain support for the BOA, so that existing applications remain functional.
The POA adds quite a bit of control and portability over and above the BOA, but because the BOA was generally easy to use programmatically, the POA may also be used in very simple ways. This avoids making the POA uselessly complex for applications that only require simple Object Adapter services.

The enhancements added by the POA include:

1. A more object-centric set of activation policies, which allow finer grained control of how CORBA objects may be activated to satisfy client requests
2. Explicit control over the threading policy to be used. When using the BOA, CORBA vendors were free to make whatever threading configuration they wished available. This is specified more strictly for the POA
3. Objects registered with a POA may be given default lifespan attributes as a group
4. A high degree of control over how CORBA requests are routed to objects, allowing sophisticated default and optimized routing models
5. The introduction of a root Object Adapter concept, RootPOA, that provides an interface for creation of nested POAs.

Many of the vendors have begun to include POA support into product releases and full POA support should be available in the near future. The resultant CORBA server code will enjoy much greater control over how it interacts with the Object Adapter and the ORB, as well as a higher level of interoperability.