Abstract: Embodiments are directed to a system for controlling access to remote services, comprising an application programming interface (API) hub configured to provide an interface between a client application and one or more remote services. The client application accesses the API hub using a common data protocol, such as OData, that is not associated with the remote services. The API hub selects a connectors based upon the targeted remote service and maps a user context associated with messages received from the client application to remote service credentials associated with the targeted remote service.

Abstract: Embodiments are directed to a system for controlling access to remote services, comprising an application programming interface (API) hub configured to provide an interface between a client application and one or more remote services. The client application accesses the API hub using a common data protocol, such as OData, that is not associated with the remote services. The API hub selects a connectors based upon the targeted remote service and maps a user context associated with messages received from the client application to remote service credentials associated with the targeted remote service.

Abstract: An in-process debugging experience can be implemented using an infrastructure that supports out-of-process debugging. A program that is to be debugged may be written in a command-line language that receives and processes input through an input loop. The interpreter for the language runs in a first process. A helper program is started in a second process, and attaches to the first process as if it were an out-of-process debugger. A debugging module is loaded into the interpreter, which provides user debugging commands that may utilize the helper program. When the program to be debugged generates a debug event, the event is received by the helper process, which uses a debug primitive to start a new instance of the input loop in the first process. Debugging commands provided by the debugging module can be entered by the user into the new instance of the input loop.

Abstract: In one embodiment of this invention, a computer system performs a method for stateless asynchronous message transmission. The method involves a first software application instantiating a listener communication thread for communication with a process of a second software application. The method involves receiving an event notification from a sender communication thread, then suspending the sender communication thread in the second process while the second process continues running. The method involves storing a thread identifier of the suspended sender communication thread and the memory address of an event message within the event notification. The method involves writing information to the suspended sender communication thread during the suspension of the sender communication thread to change values that are provided to the second software application.

Abstract: An in-process debugging experience can be implemented using an infrastructure that supports out-of-process debugging. A program that is to be debugged may be written in a command-line language that receives and processes input through an input loop. The interpreter for the language runs in a first process. A helper program is started in a second process, and attaches to the first process as if it were an out-of-process debugger. A debugging module is loaded into the interpreter, which provides user debugging commands that may utilize the helper program. When the program to be debugged generates a debug event, the event is received by the helper process, which uses a debug primitive to start a new instance of the input loop in the first process. Debugging commands provided by the debugging module can be entered by the user into the new instance of the input loop.

Abstract: In one embodiment of this invention, a computer system performs a method for stateless asynchronous message transmission. The method involves a first software application instantiating a listener communication thread for communication with a process of a second software application. The method involves receiving an event notification from a sender communication thread, then suspending the sender communication thread in the second process while the second process continues running. The method involves storing a thread identifier of the suspended sender communication thread and the memory address of an event message within the event notification. The method involves writing information to the suspended sender communication thread during the suspension of the sender communication thread to change values that are provided to the second software application.