Succes? Wat is dat?

Projectkrachten - er is meer onder de zon

Bron: projectmanagement op basis van NCB

Beoogde voordelen van fusies en overnames

Bron: http://weblog.independer.nl

Integratielagen

Bron: www.virtualsciences.nl

Heeft een fusie wel nut?

Bron: NRC next 8 sept 2016

How does RPC work

How does the RPC (Remote Procedure Call) work As an analogy, RPC works as a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote machine and the caller waits for a response to be returned from the remote machine. The below figure shows the flow of activity that takes place during an RPC call between two networked machines:

The client machine makes a procedure call that sends a request which included program number, version number, procedure number & etc to the server and waits. The thread is blocked from processing until either a reply is received, or it times out. When the request arrives, the remote machine calls a dispatch routine that performs the requested service, and sends the reply back to the client procedure. After the RPC call is completed, the client program continues. A client system connected to a database server may execute an RPC to process data on the server. For example, a computer without a hard drive may use an RPC to access data from a network file system (NFS). When printing to a network printer, a computer might use an RPC to tell the printer what documents to print.
Bron: http://www.louiewong.com/archives/154

RPC basis

Message passing RPC is a kind of request–response protocol. An RPC is initiated by the client, which sends a request message to a known remote server to execute a specified procedure with supplied parameters. The remote server sends a response to the client, and the application continues its process. While the server is processing the call, the client is blocked (it waits until the server has finished processing before resuming execution), unless the client sends an asynchronous request to the server, such as an XHTTP call. There are many variations and subtleties in various implementations, resulting in a variety of different (incompatible) RPC protocols. An important difference between remote procedure calls and local calls is that remote calls can fail because of unpredictable network problems. Also, callers generally must deal with such failures without knowing whether the remote procedure was actually invoked. Idempotent procedures (those that have no additional effects if called more than once) are easily handled, but enough difficulties remain that code to call remote procedures is often confined to carefully written low-level subsystems. Sequence of events The client calls the client stub. The call is a local procedure call, with parameters pushed on to the stack in the normal way. The client stub packs the parameters into a message and makes a system call to send the message. Packing the parameters is called marshalling. The client's local operating system sends the message from the client machine to the server machine. The local operating system on the server machine passes the incoming packets to the server stub. The server stub unpacks the parameters from the message. Unpacking the parameters is called unmarshalling. Finally, the server stub calls the server procedure. The reply traces the same steps in the reverse direction. Bron: https://en.wikipedia.org/wiki/Remote_procedure_call