Resources | developer.brewmp.com Resources | developer.brewmp.com

Developer

resources

Service class

Service classes are non-applet classes that service the caller's request in a designated process. They are also known as services and are similar to a Windows service or Unix daemon running in the background. Service classes were introduced in BREW 4.x and Brew MP, and are only supported in MOD1. See MOD, MOD1, DLL, and DLL1 for more information. Most Brew MP APIs are implemented as service classes, whereas most Brew APIs are in-process classes. .

A service class is essentially a code extension (to an applet) that is instantiated and executed outside the application context and outside the Brew Shell (or thread). The only execution context that is supported for a service class is the Kernel process, which is statically specified in the CIF of the containing module.

In Brew MP, any communication across the boundary of an execution context has to be performed through a remote invocation mechanism (invoked via a stub and skeleton code). Since a service class is always instantiated outside the application context, all calls from an applet to a service object are remote invocations. See Remote invocation of an object for more information.

Service classes that provide QCM interfaces can be registered in the CIF/MIF using the Service primitive. For a CIF example, see "CIF example for a service class" below. For more information on CIF file format, see the Resource File and Markup Reference in http://developer.brewmp.com/resources on the Brew MP website.

The service object is created in the designated process. It can only be created in the Env of the process outside the Brew Shell and therefore any service implementation or classes it uses cannot use the IShell interface. In Brew MP, a service class cannot use static APIs such as IShell.

The privileges for a service object come from the hosting process. If the service object is created as a singleton, there is only one instance of the class in the entire system.

Uses of service classes

Service classes provide the following functionality:

  • Enable privilege separation and better security

    While an in-process class is instantiated in the same execution context as its caller and therefore acquires privileges from the caller, a service class acquires privileges from its hosting environment (the kernel process). Each service class can also specify the privileges the caller must possess to access the service (see Privileges and ACLs for more information). Because a service object executes in a different execution context with its own set of privileges, Brew MP can provide privilege separation and more granular control of privileged operations.

    Privilege separation is a technique in which a program is divided into parts that are limited to the specific privileges needed to perform a specific task. For example, if full access to the file system requires privilege A, and any file can be deleted with that privilege, it is considered dangerous to grant privilege A to any application. Instead, file access should be managed and controlled by a trusted service class hosted in a process with privilege A. This service class then specifies that callers must have privilege B and exposes reduced file access functionality to them. Only privilege B needs to be granted to applications that need to gain file access (through the service class) instead of privilege A. More granular privileges or access policies can also be enforced with the use of IPrivSet in the service class. For more information, see Privileges and ACLs.

  • Can make use of pre-emptive multithreading

    Service classes can use pre-emptive multithreading because they are instantiated outside the BREW Shell (a single-threaded application environment). For an application to make use of pre-emptive multithreading, the portion of the functionality that needs to be preemptively multithreaded should be separated from the applet class and implemented in a service class. For more information on threading, see Using IThread1 in http://developer.brewmp.com/resources on the Brew MP website..

  • Enable data and resource sharing between applications

    Each application runs in its own context (protection domain) and data or resources allocated by one application cannot be directly accessed by another application. To share data between applications, a singleton service class can be used. If a service class is instantiated as a singleton, there is only one instance of the service class running in the Brew MP system. This singleton service is single point of contact for managing and controlling access to data and can provide interfaces to allow data to be shared between applications.

CIF example for a service class

A service class is declared via the Service primitive in the CIF, as shown in the following example. Note that AEECLSID_MyClass is defined as a servedclassid for MyService, which is not done for the in-process class definition.

Service {
  serviceid = AEECLSID_MyService,
  iid       = AEEIID_MyService,
  serverid  = 0,
  required_privs = {0},
  servedclassid = AEECLSID_MyClass
}

Class {
   classid = AEECLSID_MyClass,
   newfunc = MyClass_New,
}

  • MyClass_New is the constructor of the service class written in C/C++ code and is invoked when the class is instantiated by IShell_CreateInstance() or IEnv_CreateInstance() on AEECLSID_MyService.
  • serverid = 0 indicates that the service class is instantiated in the kernel process.
  • AEEIID_MyService specifies the default interface (defined in IDL and remotable) that the service class implements.

For more information on CIFs, see the Resource File and Markup Reference in http://developer.brewmp.com/resources on the Brew MP website.

Service classes publish QCM interfaces that meet remotable criteria, also referred as Directly Remotable Interfaces (DRI). DRIs are interfaces for which a remote invocation framework can marshal data and objects on the invocations across the domain boundaries. Examples of domains are processes, processors, virtual machines, etc. Remotability must be maintained for any service implementation, since the caller cannot reside in the same protection domain (Env) as the service object. The remote invocations involve data marshaling and unmarshaling by the stub and skeleton code. If the invocations need to go across process boundaries, a transport layer to bridge the stub and skeleton code is also involved. For more information, see Remote invocation of an object. For more information on Env, see Environments.