Abstract: A user interface (UI) collaboration system enables a plurality of application clients to collaborate in a heterogeneous environment. The system includes, but is not limited to, a server, a first application interface (API), and a second API. The first API is coupled to the server and is associated with a first application client that includes a first UI component. When an event is triggered by activation of a function of the first UI component, the first API reports the event to the server. The second API is coupled to the server and is associated with a second application client that includes a second UI component. The second API receives the event forwarded from the server to activate the second UI component. More than two application clients and APIs may also be included.

Abstract: In a smart card system in which applications executing in different execution contexts are allowed to communicate with each other only through shareable interface objects (SIO's), a registry mechanism is provided to mediate in inter-application communication between legacy applets, extended applets and servlets. A request by a client application for a SIO of a server application in a different execution context is routed to the registry mechanism by the system. Dependent on what types the client and server applications are, the registry mechanism provides call interfaces as would be expected by the applications to enable passing the SIO from the server application to the client application. In one embodiment, servlets and extended applets may also register and unregister their SIOs dynamically with the registration mechanism.

Abstract: Various techniques for processing service operations and for developing a service interface in a service oriented data architecture are provided. When processing a service request, a first service implementation is executed in a first operation mode. The first service implementation calls at least one second service implementation, which is executed in a second operation mode. When developing a service interface, at least one aggregated service object and at least one aggregated service operation are defined, the aggregated service operation using the aggregated service object such that the aggregation structure of the aggregated service operation matches the aggregation structure of the aggregated service object.

Abstract: System and computer program product having code for presenting event associations between events from one or more event flows on a display screen of a computer by: constructing a sequence diagram representation, the representation having timelines for the event flows and directional paths between the timelines for the event associations; and displaying the representation on the display.

Abstract: A variable task size architecture is disclosed. A system partition is included that is dedicated to system use. The system partition contains a number of specifiers that describe the number of tasks in the system memory, and for each task partition, the location and size of a task status register, the number, location and size of each of a set of task data registers, and the size and starting location of task code. Specifiers include the word size in bytes, the number of words per increment, the number of increments per partition, the number of increments per data register, and the number of data registers. In one embodiment, the number of tasks is available from an input port. The task specifiers and the number of tasks are accessible to the scheduler unit via the data flow unit when a reset signal is released.

Abstract: A method to be performed in a computer system having a function for initiating applications that allows context data to be forwarded to the initiated application in a character string includes receiving a user input made during execution of a first application. The user input requests a specific operation to be performed by a second application, the specific operation to be performed using context data from the first application. In response to the user input, the context data is stored in a memory location that is available during execution of the second application. A character string is forwarded to the second application upon its initiation, the character string including an address of the memory location, wherein the second application is to access the context data for performing the specific operation. The first application or a portal store the context data, initiate the second application and forward the character string.

Abstract: Embodiments of a message processing circuit are disclosed. In one embodiment, a high-level language is used to specify a broadcast channel and first and second thread circuits. The first thread circuit outputs messages to the broadcast channel, each message having units of data, and starts the second thread circuit, indicating position in a message at which the second thread circuit is to commence reading data. The broadcast channel receives messages from the first thread circuit and outputs data of each message along with a position code indicating position in the message of current output data. The second thread reads data from the broadcast channel at a specified position in a message. The high-level language specification is translated into a hardware description language (HDL) specification, and the HDL specification is used to generate configuration data for programmable logic. Programmable logic is configured to implement the thread circuits and broadcast channel.

Abstract: A method for processing messages ensures that every message that enters a continuous processing system is fully processed in its entirety, even in the event of a failure within the system. Messages are pushed through an execution plan that includes a set of connected “primitives” that process the message, where the primitives may be distributed across a group of servers. Messages are pushed through in accordance with a protocol that does not permit unprocessed messages to be permanently lost as they travel from input sources, between primitives, and to output sources within the execution plan. The input queue, output queue, and state (if any) associated with each primitive are saved in persistent storage at select checkpoints. If a failure occurs on a server, the server, after it starts up again, restores the primitives on that server to the input queues, output queues, and states saved at the last applicable checkpoint.

Abstract: A system and method for logging events processed by an operating system is provided. The events logged can include interrupt and non-interrupt events, and can include user-defined events. Information concerning the interrupt events is initially written, during event handling time, into a first buffer while information concerning non-interrupt events is initially written, during event handling time, into a second buffer. Information from the two buffers is then written to a third buffer not during event handling time. Separating the interrupt event buffer from the non-interrupt event buffer rather than having one buffer, and writing relatively small amounts of data during event handling time to memory, rather than transporting data to slower non-memory mapped devices allows the event logger to be less intrusive and facilitates greater accuracy in event logging.

Abstract: Applications or operating system components requiring a SKU, or other indicator of an operating system, make a call to an API. The calling application passes an indicator of the most current version of an operating system known at the time of the application creation as an argument. This argument may be an indictor of the operating system version, build number, and service pack version, for example. The called API may reference a table of operating system SKUs with the indicator of the most current operating system known to the calling application. If found, the API returns the corresponding SKU to the calling application. If not found, the API returns the SKU corresponding to the closest sequential match to the passed in indicator. The calling application may then execute believing it is using the operating system corresponding to the returned SKU.

Abstract: Techniques are provided for quickly reacquiring mutual exclusion locks (QRLs), such as in the case in which a single process repeatedly acquires and releases the lock and in which no other process attempts to acquire the same lock. When the first holder of a QRL first acquires the lock, it biases the lock to itself. Bias may be directed in different way or at different times in some realizations. Biasing may involve a one-time compare-and-swap instruction. Thereafter, this bias-holder can reacquire and release the lock free of atomic read-modify-write operations. If a second process attempts to acquire a QRL, then the lock may revert to a “default lock”. Any standard mutual exclusion lock may be used as the default lock. A QRL lock may be reinitialized so that it can be rebiased. Rebiasing may be valuable in the case of migratory data access patterns.

Abstract: A message is buffered and processing statistics are associated with the message, including characterizations of whether a process instance is to process the message, a number of process instances handling the message, and a number of process instances that have processed the message. A process instance may be generated to process content of the message depending on the message. The message may be dequeued based on the processing statistics. For example, if the processing statistics indicate that no process instances are handling the message and no process instance is to process content of the message. Also, if the content of the message is to be processed by a threshold number of process instances, the message is only dequeued if the processing statistics indicate that the threshold number of process instances have processed the content of the message.

Abstract: An apparatus, system, and method are disclosed for supporting service components written in non-native runtime code in a Service Component Architecture (“SCA”). A read module is included to read an implementation type definition having metadata identifying executable code that executes a new implementation type. A receive module is included to detect a dynamic service call to a service component having the new implementation type. The dynamic service call is defined in an SCA message from a calling SCA component. A passing module is included to pass the dynamic service call to a predefined SCA implementation handler associated with the new implementation type. The SCA implementation handler includes native runtime code and implementation logic for executing the dynamic service call by executing non-native runtime code that returns a result to the SCA implementation handler. A packaging module packages the result in an SCA return message to the calling SCA component.

Abstract: A method and wireless mobile device runs different types of applications and groups a set of common application interfaces (APIs) that are associated with an application type to produce an application container (902). The wireless mobile device and method translates calls between at least one of the linked or grouped common APIs of the application container and a shared API that is shared for example among applications of different types (904). If desired the method and device also groups a set of common application interfaces associated with another application type to produce another application container. The applications of different types use APIs from the multiple application containers. In one embodiment, the translating of calls is accomplished by employing a class loading structure using, for example, a class loader that looks at certain path locations to obtain resources.

Abstract: Systems, methods, and computer program products are provided for adapting service entities using a declarative approach in a service framework. In accordance with one implementation, a method is provided for adapting service entities. The method includes the steps of retrieving at least one software entity from a first repository in response to a first input and receiving a declaration from a user for adapting the software entity. The method further includes the steps of adapting the software entity to an adapted software entity based on the declaration and storing the adapted software entity in a second repository.

Abstract: A set of embodied Application Program Interface(s) (112) are provided for facilitating a method of presenting a presented user-interface shell (UIS) (114) that cooperates with a servicing user-interface shell (UIS) (116). The method includes receiving data indicative of one or more tasks to be completed, coordinating the completion of said one or more tasks, and returning control to said presented UIS (114).

Abstract: A system and method for validating whether communications between a device driver and a hardware device conform to a communication specification is presented. A validation module obtains a communication specification identifying rules for validating whether communications between a device driver and a hardware device conform to the specification. A redirection module redirects communications between the device driver and the hardware device to the validation module. Based on an individual communication, as well as the context in which an individual communication is made, the validation module validates whether the communication conforms to the communication specification.

Abstract: First data associated with a task originating from one of a plurality of applications may be received via a communications network. Thereafter, an entity to which the task has been assigned may be identified to allow for an associated delivery context to be determined. A format of the first data may be converted so that it is compatible with the determined delivery context to generate second data. This second data may be transmitted to a node associated with the entity via the communications network. A user interface associated with the first node may be operable to initiate one or more transactions associated with the task using the second data. Related techniques, apparatuses, systems, and computer program products are also described.

Abstract: Disclosed are systems and methods to automatically transform generic software code into operator specific code. For instance, in one embodiment, there may be an engine for transforming generic software code into operator-specific software code, the engine comprising: a module for reading generic software code, wherein the generic software code includes at least one generic control indication; a processing module including: a module for extracting the at least one generic control indication from the generic software code; a module for determining at least one aspect from the generic control indication, wherein the at least one aspect corresponds to operator specific requirements, a module for determining an integration instruction, a module for inserting the generic control indication with the at least one aspect according to the integration instruction; and a module for generating operator-specific software code which includes the at least one aspect.

Abstract: The present invention addresses the problem of linking cross-process and cross-thread subtransactions into a single user transaction. The mechanism of the present invention employs bytecode inserted probes to dynamically detect out of process correlating tokens in an inbound request. The bytecode inserted probes retrieve the correlating token in the inbound request. Based on the correlating token retrieved, the bytecode inserted probes are then used to dynamically determine if the inbound user request should be recorded and linked to a transaction that began in another thread or process.