The first thing to understand is that you will almost always have to get a home object which represents the starting point for interactions in that package. Such that if you wanted information on access control you would use a JNDI lookup to retrieve AccessControlHome, or for PumaHome if you want to get information on the Portal User interface. Once you have the Home you will need to get either the Model or the Provider object depending on the needs of the code. Next we will look at the most common packages and their uses.
This package will contain information regarding access control information on various resources. You can check the ACL data on any item that supports the Identifiable interface(which is most everything in portal). So this would include Pages, Portlets, Containers, whatever you might have. you can pass in and either get the entire role data set or check to see if certain users have a specific permission, or if the current user has a specific permission. You could use this to customize visible data in your portlets, and on your pages depending on what was needed for the environment.
This next package is useful for customizing the Portal login/logout mechanism. These will only be triggered when you try to access a Portal protected resources. This replaces the customization that used to be made in the LoginUserAuth classes by now adding them to the Portal login filter chain. One thing to be aware of is the difference between implicit and explicit login/logout. The Implicit login is where a user us already authenticated to WebSphere AppServer but then attempts to reach a portal resource. They will then go through the Portal implicit login chain.
This package has many providers that will see some of the most use out of the other ones. With this package you can retrieve a list of languages the Portal supports, the markup that the Portal supports, information about the navigation, content, navigation selection, portlets, themes, skins and helpers to localize resources when presenting them to users. All of these models will be read only while the subpackage com.ibm.portal.model.controller will give you write access to all of these. All of these will be scoped to the user making the request. With the controller package you can create pages, add portlets to the page and remove them, set skins on the page, alter properties about all of these including ordinality. A developerworks article is in the plan for this from support to show examples of the most common questions using the controller SPI
The providers in this package will allow you to traverse the tree for navigation of the current user. they can be useful in creating breadcrumbs and creating your own custom navigation portlets. These along with the com.ibm.portal.state package can be used to create links to do a grand variety of actions within portal. Please see Advanced URL helpers for a detailed sample on using the state package to create links to various Portal resources.
com.ibm.portal.portlet and com.ibm.portal.portletmodel
These two packages provide a lot of information concerning the various layers of portlets they can be used to make changes to the portlet configuration and also can retrieve preferences layers for review.
Also known as PUMA this is the usermanagment part of the SPI, with it you can do user management, and queries. For more on PUMA please see PUMA whitepaper
This covers the majority of the SPIs that customers use, and can do 90% of what you need to do in your custom Portal environment for management and administration.