When a user presses a button on the web page or activates a control that requires information from the server, the control and the page support code will work in tandem to determine the request to send to the OM.
Depending on the type of request; the Remote Access component will send the request to one of a number of service points available in the OM.
There are many services which a client can invoke directly in the OM; the OM will process the request and return the result to the calling client via the OM Remote Access component.
In other cases, the request may be routed to the appropriate application component (Business Object) which is hosted on the OM.
In all cases, access to the OM is via the Remote Access component, even for login or password modification.
All requests other than Login and Password change must be accompanied by a valid Session ID.
The Login and password change are accompanied by a user-id and password that verify the authenticity of the person or system attempting to access the OM.
The Remote Access is the front door of the OM and it guards access to the rest of the system very carefully.
Any service in the OM may potentially call on many other services in the OM to satisfy a given request.
The communication between high level services will almost always be facilitated by passing an OMO from service to service.
At lower levels however, particular methods within a service may be called directly by another service to initiate some particular type of processing or to retrieve some particular piece of information.
The benefit of a routed request is that it is asynchronous at will happen as processing and resources are available.
The benefit of a direct call to a service method is of course that the request can take place inline as necessary to meet current requirements.
All services in the OM utilize common facilities in the OM, such as diagnostic logging, database access services and OMO management services.
These same facilities are available to business objects (application programs) that execute in the OM Domains.
There are a number of other facilities that the business objects have access to such as rule processing, database and long transaction management, translation and globalization, permissioning and security.
The key essence of the OM is that it has a wide range of services available for the support of its own functionality as well for the use of any supported application.
Not every business object is going to use all of the functionality, but it is available when needed.
There are also a number of independent managers within the OM, responsible for managing various aspects of the OM, such as scheduling, script execution or Sessions.
The OM also manages its services and managers.
Each service, manager or facility in the OM that has the potential of faulting for any reason, is monitored by the OM System Manager Monitor to ensure the integrity of the service or facility and its continued proper functioning.
In the same fashion, the OM monitors all attach business applications to ensure that they continue to run without fault.
When a business application does cause a fault, the effects are isolated and the business application execution is stopped and an error response is returned to the calling client.