| Runtime Environment Specification, Java Card Platform, v3.0.1, Connected Edition |    
|
| C H A P T E R 7 |
|
Inter-application Communication |
This chapter describes issues related to how applications communicate in the Connected Edition.
On the Java Card Platform, Connected Edition, communication between applications (web applications or applet applications) is constrained by two orthogonal security containment mechanisms:
Applications from different application groups can communicate indirectly through static fields and methods of commonly visible classes or by the means of Java Card RE entry point objects and global arrays that are also, by definition, commonly visible. Context isolation also applies to objects exchanged by these means. See Section 2.4, Context Isolation Basics.
FIGURE 7-1 depicts the orthogonal security containment mechanisms and different means of inter-application communications.
FIGURE 7-1 Context Isolation, Code Isolation and Inter-Application Communications
To enhance communications across group contexts, the Java Card Platform, Connected Edition, introduces the object ownership transfer mechanism. This mechanism allows an application to transfer the ownership of objects it owns to other applications.
An application can communicate with another application using the following two inter-application communication facilities:
These two inter-application communication facilities build on the shareable interface mechanism and the mechanism for transfer of objects’ ownership.
The object ownership transfer mechanism allows an application to transfer the ownership of objects it owns to other applications. These objects can then be passed as parameters or return values of SIO methods calls. Furthermore, these objects can also be passed from the former owner to the new owner through static fields or as parameters or return values to static methods of commonly visible classes or by the means of Java Card RE entry point objects and global arrays.
Once an application has transferred the ownership of an object it owns to another application, the application that originally owned the object can no longer access it, even though it may still hold a reference to it. When an object’s ownership is transferred to an application bound to a group context, all other applications from that same group context have access to the object.
Object ownership transfer MUST only apply to direct instances of a well-defined set of classes called Transferable Classes. Transferable classes can be categorized into two types:
See Section 6.9.3, Ownership of Transferable Objects for more details on the ownership assignment of instances of implicitly and explicitly transferable classes.
The Java Card Platform MUST support, and only support, the following list of implicitly transferable classes:
The set of implicitly transferable classes that subclass the Throwable class MAY be extended by standards bodies provided these classes respect the contract of implicitly transferable classes on immutability defined above.
The Java Card Platform MUST support, and only support, the following list of explicitly transferable classes:
The ownership of the objects referenced by the components of an array MUST NOT be affected when the ownership of the array is transferred. Especially, since multi-dimensional arrays are arrays of arrays, when the ownership of a multi-dimensional array is transferred the ownership of the nested arrays MUST NOT be affected.
Strings computed at run time are not mutable objects but may encapsulate sensitive information such as passwords which must not be shared by default. Strings computed at run time MUST NOT be, by default, implicitly transferable. Such newly created strings MUST stay bound to their creator's group context until they are explicitly interned by calling their intern() method, in which case they MUST become context-free and may be passed and shared between group contexts without any firewall restrictions.
A call to the intern() method on a String object MUST return a canonical representation for the String object which is not bound to any context (group context or Java Card RE context). The String object may be added to the pool of strings maintained internally by the String class (and therefore common to all contexts). If the pool already contained a string equal to that String object, then the string from the pool MUST be returned. Otherwise, the String object MUST be made context-free then added to the pool and a reference to that String object MUST be returned.
The Java Card Platform MUST NOT intern String objects passed as parameters to an API method by an application or computed at runtime from such parameters, if not otherwise stated in the API specification. An extension library SHOULD clearly state if any of its methods intern String objects passed as parameters or computed at runtime from such parameters.
The Java Card Platform MUST support the following javacardx.framework.JCSystem method for testing the transferability of an object:
The Java Card Platform MUST support transferring objects’ ownership by calls to the javacardx.framework.JCSystem.transferOwnership methods.
Applying transfer of ownership on instances of implicitly shared classes MUST have no effect on the instances’ ownership.
Applying transfer of ownership to an array of objects MUST NOT affect the ownership of the objects referenced by the components of the array (transfer of ownership MUST be “shallow” as opposed to “deep”).
Attempting to transfer ownership of instances of classes that are not transferable classes MUST result in a security exception being thrown.
Attempting to transfer ownership of instances which are not direct instances of classes that are transferable classes MUST result in a security exception being thrown.
Attempting to transfer ownership of objects not owned by the caller’s group context MUST result in a security exception being thrown.
Attempting to transfer ownership of objects to the Java Card RE context MUST result in a security exception being thrown.
Transfer of ownership MUST be subject to access control. When a JCSystem.transferOwnership method is invoked, a security check MUST ensure that the permission javacardx.framework.ContextPermission with the target canonicalized application URI and the action transfer is granted.
To facilitate interactions between server applications and their clients through shareable interfaces, the javacardx.framework.JCSystem.copyTransferable method allow for applications to create copies of objects they own and want to share only the state with other applications. Using this method, an application may create Defensive Copies of explicitly transferable objects, which are typically mutable objects, in order to only transfer the ownership of the copies. This allows for the application to continue processing with the original objects.
The copy operation performed by the copyTransferable method is a "shallow copy" of the object being copied, not a "deep copy" operation:
Transfer of ownership MUST be synchronized on the object being transferred to avoid concurrency issues.
Transfer of ownership MUST be an atomic operation. Once the ownership transfer to another application has been successfully performed, the object is owned and MUST stay owned by that other application even in the occurrence of a platform reset and that until it is explicitly transferred again or disposed of.
The inter-application communication facility provided by the Java Card Platform, Connected Edition, extends the classic shareable interface mechanism and allows for all application models, including classic applet applications, extended applet applications and web applications, to interact through shareable interface object-based services in a unified way. This facility also ensures a seamless integration of classic SIO registration and lookup.
The inter-application communication facility allows for:
Web applications and extended applet applications can lookup and register SIO-based services to a global service registry. Classic applet applications cannot use this facility directly. To ensure the seamless integration of the classic SIO registration and lookup, the service registry lookup mechanism uses the classic Java Card RE SIO lookup mechanism when an AID-based service URI cannot be found in the service registry.
The javacardx.facilities.ServiceRegistry class allows for applications to register SIO-based services they want to expose to other applications. Service-providing applications (server applications) may typically, but not necessarily, run in group contexts different from those of the client applications.
The ServiceRegistry instance MUST be a singleton. It MUST be a permanent Java Card RE entry point object. It is retrieved by calling the ServiceRegistry.getServiceRegistry method.
An application MUST NOT be allowed to use the service registry until it is registered, that is until it has been assigned an application URI. In particular, an extended applet MUST NOT be allowed to use the ServiceRegistry singleton instance within its install method until it is duly registered by a call to its register method.
FIGURE 7-2 depicts the interactions between the different components and actors of the SIO-based service registry. The numbering indicates a typical interaction sequence with possible alternatives. Colors indicate common ownership of interacting objects.
FIGURE 7-2 SIO-based Service Registry Interactions (Collaboration Diagram)
Services MUST be shareable interface objects (SIO). They MUST implement interfaces that extend the javacard.framework.Shareable interface.
A service MUST be uniquely identified in the registry with service URI. Service URIs are in the service namespace and MUST use the URI scheme sio. The service namespace MUST be partitioned as follows:
Only one service may be associated with a service URI.
The service registry MUST implement the following requirements:
As a result of service URI normalization, standard service URIs that use the default registry-based URI authority and those that use the aid registry-based URI authority are equivalent. For example, the two following standard service URIs designate the same entry in the registry: sio:///standard/auth/holder/global/owner/fingerprint, sio://aid/standard/auth/holder/global/owner/fingerprint.
The Java Card Platform, Connected Edition, does not currently define any platform services. The /platform namespace is currently not used for service registration and is reserved for future use.
An application MUST NOT be allowed to register a service under the reserved platform service namespace rooted at sio:///platform/.
The standard service namespace rooted at sio:///standard/ specifies an extensible set of standard services that any application may implement. The intent for this namespace is to define a set of service URIs for common, well-defined services.
The standard authentication service namespace rooted at sio:///standard/auth/ defines standard services for card holder and other user authentication. See Section 6.4.1, Scheme-specific Authenticators for more details about standard authentication services. See TABLE 7-1 for the list of standard authentication services a Java Card Platform MUST support. The definition of additional authentication service URIs in the standard authentication service namespace is reserved for this specification. In particular, an application MUST not be able to register a service with a URI in the standard authentication namespace that is not one defined by this specification.
An application, if authorized, MUST be allowed to register a service under the standard service namespace rooted at sio:///standard/.
The set of standard services MAY be extended by standards bodies. It is suggested that the service URI path, relative to the standard service root URI sio:///standard/, be prefixed in accordance with the reverse domain name convention for package naming suggested by The Java Programming Language Specification. The prefixes javacard and javacardx are reserved by this specification.
|
javacardx.framework.SharedPINAuth |
||
|
javacardx.framework.SharedPINAuth |
||
|
javacardx.framework.SharedPINAuth |
||
See TABLE 7-1 for the standards body-defined service naming convention a Java Card Platform MUST support.
An application may define, meaning register, services in the application-defined service namespace. Application-defined services MUST be named relatively to their application's root service URI. For example, if an application’s URI is /transit/pos, the application’s root service URI is sio:///transit/pos and a well-formed service URI could be sio:///transit/pos/ticketbook.
An application, if authorized, may register a service under its own service namespace rooted at sio://<app-path>/, where <app-path> represents the application’s URI path, either a web application URI represented by its context path or an applet application URI represented by its RID and PIX AID components. See TABLE 7-2 for the application-defined service naming convention a Java Card Platform MUST support.
An application MUST NOT be allowed to register a service under a URI rooted in another application’s namespace.
To provide a service to other applications, an application MUST register a service factory under a unique service URI. Service factory objects MUST implement the javacardx.facilities.ServiceFactory interface.
The application MUST call the ServiceRegistry.register method and provide a legal service URI and a service factory object to register the service.
The service URI passed for registration MUST be legal for the application or a security exception is thrown. A legal service URI for registering a service is of one of the following types (after canonicalization):
Registering a service factory with a service URI already used by the same application MUST result in the new registration overwriting the old one.
The service registry MUST support the following requirements:
Registering a service factory with a standard service URI already used by another application MUST result in a security exception being thrown.
Registration of service factories MUST be subject to access control. When the ServiceRegistry.register method is invoked, a security check MUST ensure that the permission javacardx.facilities.ServiceRegistryPermission with the target canonicalized service URI and the action register is granted.
Applications may register service factories anytime during their lifetime[2].
An application may unregister a service factory it previously registered at any time. To unregister a service factory, an application MUST provide the service URI with which the service factory was registered.
The application MUST call the ServiceRegistry.unregister method and provide a legal service URI.
The service URI passed for unregistration MUST be legal for the application or a security exception is thrown. A legal service URI for unregistering a service is of one of the following types (after canonicalization):
Attempting to unregister a service factory registered by another application, either under its own namespace or under the standard service namespace, MUST result in a security exception being thrown.
Unregistration of service factories MUST be subject to access control. When the ServiceRegistry.unregister method is invoked, a security check MUST ensure that the permission javacardx.facilities.ServiceRegistryPermission with the target canonicalized service URI and the action unregister is granted.
Applications may unregister service factories anytime during their lifetime[3]. Attempting to unregister a service factory that is not, or is no longer, registered has no effect.
An application may look up a service registered under its own service namespace, by any other application under that application’s own namespace or the standard service namespace, provided it has the required permissions. To look up a service, an application MUST provide the URI of the service and an optional object parameter.
The service registry MUST look up the registered service factory and it MUST invoke its create method with the service URI and the optional object parameters. The create method executes within the group context of the owning application, meaning the application which registered the service factory. The service factory may return a new instance or the same instance at each invocation. The service factory may use the service URI and the optional object parameters to determine the service instance to create and initialize and/or return, such as when the same service factory object has been registered under multiple service URIs.
The application MUST call one of the ServiceRegistry.lookup methods and provide a service URI. The value of the optional lookup parameter may typically be an SIO or an implicitly transferable object.
Lookup of services MUST be subject to access control. When the ServiceRegistry.lookup methods are invoked, a security check MUST ensure that the permission javacardx.facilities.ServiceRegistryPermission with the target canonicalized service URI and the action lookup is granted.
The registry MUST delegate to the classic Java Card RE SIO lookup mechanism if all the following conditions apply:
The delegation to the classic Java Card RE SIO lookup mechanism MUST be equivalent to invoking the JCSystem.getAppletShareableInterfaceObject method with the AID instance corresponding to the looked up service URI and the optional data parameter converted to a byte primitive type. See Runtime Environment Specification, Java Card Platform, v3.0.1, Classic Edition.
If any of the above conditions does not apply, the lookup operation MUST return as if no service factory was registered for the looked up service URI.
This fallback mechanism does not apply to other registry operations.
This mechanism primarily allows for the integration of classic applet applications. Extended applet applications can look up classic applet server applications. Extended applet applications can also use this mechanism to look up other extended applet applications that expose shareable interfaces via the Applet.getShareableInterfaceObject method.
| Note - Backward compatibility support on the Java Card Platform, Connected Edition, includes mechanisms that guarantee the thread-safety of classic applet applications when invoked through SIO methods calls from concurrently executing extended applet applications and web applications[6]. |
Classic applet applications may also look up extended applet server applications, provided they expose Java Card Platform, v2.2.2-compatible shareable interfaces via the Applet.getShareableInterfaceObject method.
The role-based security API for SIO-based services consists of the following methods of the javacardx.framework.JCSystem class:
These methods may be invoked from within the method of any SIO (SIO-based services and other unregistered SIOs) or code that it calls, such as library code. These methods may also be invoked from within the create method of an SIO-based service factory to check the authorization to access a service prior to returning it to the client.
A service factory MUST remain registered until it is removed from the registry by the application that registered it or when that application is forcefully deleted. See Section 8.1, The Card Manager Application for more details on application instance deletion.
The registry MUST ensure that service factory objects are persistent across card sessions. Therefore, applications do not have to hold on to references to these objects to ensure their persistence.
The ServiceRegistry implementation MUST be thread safe to account for concurrent registrations, unregistrations and lookups. Though, it SHOULD not serialize the calls to the lookup methods. A service factory object may, therefore, be concurrently looked up. The application developer must properly account for thread safety in the create method of the service factory.
Each thread is associated to a current active context and namespace. When entering a different group context through an SIO method call, the thread’s current active context and namespace MUST be changed to the owner context of the SIO. Upon return to its previous group context, the thread’s current active context and namespace MUST be restored. See Section 2.7.2.2, Per-Thread Active Context and Active Namespace.
The ServiceRegistry singleton instance MUST be a permanent Java Card RE entry point object and therefore MUST NOT participate in any application transaction. The ServiceRegistry class MUST be annotated with the NOT_SUPPORTED TransactionType annotation, see Section 2.9.2, Transaction Demarcation. All registration operations MUST nevertheless be atomic and MUST ensure that the service registry is at all time consistent.
The event notification facility provided by the Java Card Platform, Connected Edition, allows for applications to be notified by the Java Card RE, or by other applications, about particular conditions. When these conditions occur, they are encapsulated in objects called events. The event notification facility builds on the inter-application communication facility and allows for web applications and applet applications to communicate asynchronously[7] with each other through events.
The event notification facility allows for:
Web applications and extended applet applications can use a global event registry to fire events and/or register for event notification. Classic applet applications cannot use this facility directly.
The javacardx.facilities.EventRegistry class allows for applications to fire events and/or register for notification of events fired by the Java Card RE or other applications. Applications firing events (event-producing applications) may typically, but not necessarily, run in group contexts different from those registering for notification of these events (event-consuming applications).
The EventRegistry instance MUST be a singleton. It MUST be a permanent Java Card RE entry point object. It is retrieved by calling the EventRegistry.getEventRegistry method.
The event registry MUST operate in the Java Card RE context, therefore, it MUST be defined as a Java Card RE entry point object.
An application MUST NOT be allowed to use the event registry until it is registered, that is until it has been assigned an application URI. In particular, an extended applet MUST NOT be allowed to use the EventRegistry singleton instance within its install method until it is duly registered by a call to its register method.
FIGURE 7-3 depicts the interactions between the different components and users of the event registry. The numbering indicates a typical interaction sequence. Colors indicate common ownership of interacting objects.
FIGURE 7-3 Event Registry Interactions (Collaboration Diagram)
Events are shareable interface objects (SIO). They MUST extend the javacardx.facilities.Event class, which implements the javacardx.facilities.SharedEvent interface (which itself extends the javacard.framework.Shareable interface).
An event type MUST be uniquely identified in the registry with an event URI. Event URIs are in the event namespace and MUST use the URI scheme event. The event namespace MUST be partitioned as follows:
Each event object MUST, at the minimum, encapsulate the URI identifying the event and its source, the application that created it.
The URI identifying the source of an application-defined, a standard application, or a resource event MUST be in the namespace of the application that created it or on behalf of which the event was created and fired by the platform. The event’s source MUST NOT be overwritable.
The URI identifying the source of a platform event MUST designate the platform and MUST be ///platform.
The source of an event may be retrieved by calling the Event.getSourceURI method.
The URI identifying an event object MUST be assigned to the object at instantiation-time and MUST NOT be overwritable. The URI of an event may be retrieved by calling the Event.getURI method.
The event registry MUST implement the following requirements:
As a result of event URI normalization, platform event URIs, as well as standard application and resource event URIs that use the default registry-based URI authority, and those that use the aid registry-based URI authority are equivalent. For example, the two following platform event URIs designate the same entry in the registry: event:///platform/clock/resynced and event://aid/platform/clock/resynced.
The platform event namespace rooted at event:///platform/ defines a set of platform events that encapsulate specific Java Card RE conditions. This includes a card lifecycle event such as a real-time clock resynchronization. See TABLE 7-3 for the list of platform events a Java Card Platform MUST support.
Instances of Event that encapsulate platform events MUST be owned by the Java Card RE.
The standard event namespace rooted at event:///standard/ defines an extensible set of standard events that any application may fire or that may be fired by the platform on behalf of an application. This namespace is intended to define a set of event URIs for common, well-defined conditions.
The standard application and resource event namespaces rooted at event:///standard/app/ and event:///standard/rsrc/, respectively, define a set of event URIs for common, well-defined application and resource-related conditions, such as application and resource lifecycle events. See Section 8.1, The Card Manager Application for more details about application lifecycle events. See TABLE 7-3 for the list of standard application and resource events a Java Card Platform MUST support. The definition of additional event URIs in the standard application and resource event namespaces is reserved for this specification. In particular, an application MUST not be able to create or fire an event with a URI in the standard application or resource event namespaces that is not one defined by this specification.
Instances of Event created by the Java Card RE on behalf of an application and that encapsulate standard application and resource events MUST be owned by the Java Card RE.
An application, if authorized, may fire an event under the standard event namespace rooted at event:///standard/.
An application MUST NOT be allowed to create or fire an event under the platform event namespace rooted at event:///platform/.
The set of standard events MAY be extended by standards bodies. It is suggested that the event URI path, relative to the standard event root URI event:///standard/, be prefixed in accordance with the reverse domain name convention for package naming suggested by The Java Programming Language Specification. The prefixes javacard and javacardx are reserved by this specification.
See TABLE 7-3 for standards body-defined event naming conventions the Java Card Platform MUST support.
|
//<context path>[8] |
||
An application may define events in the application-defined event namespace. Therefore, application-defined events MUST be named relatively to their application's root event URI. For example, if an application URI is /transit/pos, the application’s event root URI is event:///transit/pos and a well-formed event URI could be event:///transit/pos/ticketbook/overdraft. See TABLE 7-4 for the application-defined event naming convention a Java Card Platform MUST support.
The base Event class can be used by applications to notify about events that do not have to encapsulate domain-specific information and behavior. When an event object must encapsulate domain-specific information and behavior, a new event object must be defined by extending the Event class.
An application, if authorized, may fire an event under its own event namespace rooted at event://<app-path>/, where <app-path> represents the application’s URI path, either a web application URI represented by its context path or an applet application URI represented by its RID and PIX AID components.
An application MUST NOT be allowed to fire an event under a URI rooted in another application’s namespace.
An application may register for notification of any event, fired either by the platform or any other applications, provided it has the required permissions. To register its interest in an event using the event notification facility, an application MUST register an event notification listener for that event’s URI. Event listener objects MUST implement the javacardx.facilities.EventNotificationListener interface.
The registering application MUST call one of the EventRegistry.register methods and provide:
Registering several event listener objects for the same source and event URIs MUST result in each of the listeners being called upon event notification.
Registering the same event listener object several times for the same source and event URIs MUST result in the listener being called only once upon event notification.
The same event listener object may be registered for multiple source and event URIs.
The event notification facility MUST allow for applications to register for events produced by an event source (an application or an application’s resource) that is not yet installed. When an event source is uninstalled, the listeners of events from this source registered by other applications MUST stay registered.
Registration of event listeners MUST be subject to access control. When the EventRegistry.register method is invoked, a security check MUST ensure that the permission javacardx.facilities.EventRegistryPermission with the target canonicalized event URI and the action register is granted.
Applications may register event listeners anytime during their lifetime[9].
An application may unregister an event listener it previously registered at any time.
The application MUST call one of the EventRegistry.unregister methods and provide:
Only event listeners previously registered by the calling (current) application for the specified source and event URIs MUST be unregistered. The event listener passed may be null, in which case all listeners registered by the calling (current) application for that source and event URIs are removed.
Unregistration of event listeners MUST be subject to access control. When the EventRegistry.unregister method is invoked, a security check must ensure that the permission javacardx.facilities.EventRegistryPermission with the target canonicalized event URI and the action unregister is granted.
Applications may unregister event listeners anytime during their lifetime[10]. Attempting to unregister an event listener that is not, or is no longer, registered has no effect.
An application may fire an event with a URI from its own event namespace or the standard event namespace, provided it has the required permissions.
The application MUST call one of the EventRegistry.notifyListeners methods and provide an instance of the Event class with an event source URI that identifies the firing application or a resource in that application's namespace, and an event URI, which identifies the event type, a standard event or an application-defined event in the firing application’s event namespace.
The URI of the event passed for notification MUST be legal for the application or a security exception is thrown. A legal event URI is of one of the following types (after canonicalization):
The event registry MUST look up all event listeners registered for that event’s source URI and event URI and it MUST invoke each listener’s notify method in sequence passing the event as a parameter. The notify methods execute within the group context of their owning applications, meaning the applications which registered the event listeners. The order in which the event listeners may be notified is nondeterministic.
Event notification MUST be subject to access control. When an EventRegistry.notifyListeners method is invoked, a security check MUST ensure that the permission javacardx.facilities.EventRegistryPermission with the target canonicalized event URI and the action notify is granted.
Since events (application-defined events and standard application and resource events) are shareable interface objects, role-based security for events uses the same API as for role-based security for SIO-based services, see Section 7.3.4, Role-based Security for SIO-based Services.
In addition, the EventRegistry.notifyListenersInRole methods allow for specifying a client security role. The notification process is identical to the one described in Section 7.4.2, Event Listener Registration with the difference that only the listeners belonging to the client security role and to the notifying application itself MUST be notified.
An event listener MUST remain registered until it is removed from the registry by the application that registered it or when that application is forcefully deleted. See Section 8.1, The Card Manager Application for more details on application instance deletion.
The registry MUST ensure that event listener objects are persistent across card sessions. Therefore, applications do not have to hold on to references on these objects to ensure their persistence.
The EventRegistry implementation MUST be thread safe to account for concurrent registrations, unregistrations and notifications. However, it SHOULD not serialize the calls to the notifyListeners methods. An event listener object may, therefore, be concurrently invoked. The application developer must properly account for thread safety in the notify method of the event listener.
Event listener notifications MUST be handled by the event registry in Java Card RE-owned threads. The thread notifying a particular application-owned listener MUST belong to the Java Card RE context and MUST, therefore, switch to the application's group context when calling the event listener's notify method. A single Java Card RE-owned thread MUST handle the notification of all the listeners for a single event (a single call to an EventRegistry.notifyListeners method). All concurrent calls to the EventRegistry.notifyListeners methods MUST be handled concurrently in separate threads. An exception thrown by an event listener during a notification MUST be caught by the Java Card RE-owned notification thread and MUST NOT result in the notification of the remaining listeners being aborted.
By default, the event-producing application's thread MUST wait until the event notification is complete, meaning all listeners have been notified. An application may choose not to wait for all listeners to be notified by setting the noWait argument of the EventRegistry.notifyListeners method to true. When this occurs, the EventRegistry.notifyListeners method will immediately return and the notification will be handled asynchronously by a Java Card RE-owned event notification thread.
Because the notification of all the listeners for a single event (a single call to an EventRegistry.notifyListeners method) is performed in sequence (serially), a listener not returning from its notify method may block the event notification and, therefore, some listeners might not get notified until the blocking listener returns.
A Java Card Platform implementation MAY limit the effects of an unresponsive listener application when notifying of some standard application (card management-related) events or platform events by performing the notification of all or some of the listeners asynchronously. The sequence of notification can, therefore, not be guaranteed on card management-related standard application or platform events. However, a Java Card Platform implementation MUST guarantee that all applications which registered for such an event have had at least one of their registered event listeners invoked. A Java Card Platform implementation MUST do its best to notify all listeners of all applications.
Asynchronous notification MAY be used by a Java Card Platform implementation to prevent an unresponsive listener application from interfering with the application instance deletion sequence detailed in Section 8.9, Deletion of Application Instance.
TABLE 7-5 lists all card management-related standard application or platform events for which the notification is not guaranteed to be sequential and complete.
Events are shareable interface objects (SIO). Therefore, calling the event methods results in context-switching to the group context of the application that fired the event or to the Java Card RE context, if the event was fired by the platform. See Section 7.3.7, Per-Thread Active Context for more details.
The EventRegistry singleton instance is a permanent Java Card RE entry point object and therefore MUST NOT participate in any application transaction. The EventRegistry class MUST be annotated with the NOT_SUPPORTED TransactionType annotation, see Section 2.9.2, Transaction Demarcation. All registration operations MUST nevertheless be atomic and MUST ensure that the event registry is at all time consistent.
| Runtime Environment Specification, Java Card Platform, v3.0.1, Connected Edition | 5-30-09 |
|
Copyright © 2009 Sun Microsystems, Inc. All rights reserved.