The concept of this course is that we want to understand how the web and distributed enterprise application environments work. We want to do that by starting to explore how to communicate over a network at the lowest level of abstraction (normally) available to programmers, the [socket API](https://en.wikipedia.org/wiki/Network_socket). From there, we work our way up step-by-step higher levels of abstraction, i.e., simpler and more powerful API stacking on top of each other (and ultimately grounded in sockets). This way, we will gain a solid understanding how distributed applications and the web work. We will be able to look at a website and immediately have a rough understanding of how it may work, down to the nuts and bolts. For each level of abstraction that we explore, we therefore always learn example technologies. 

As said, we start at the very bottom: Communication in distributed systems today is usually either based on the [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol) or [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol). Both protocols are accessed via the [socket API](https://en.wikipedia.org/wiki/Network_socket), for which we provide [examples](http://github.com/thomasWeise/distributedComputingExamples/tree/master/sockets/) in both [C](http://github.com/thomasWeise/distributedComputingExamples/tree/master/sockets/c) and [Java](http://github.com/thomasWeise/distributedComputingExamples/tree/master/sockets/java). As part of these examples, we also show how text can be encoded in Java and how to construct servers which can process multiple requests in [parallel](http://github.com/thomasWeise/distributedComputingExamples/tree/master/sockets/java/src/MinHTTPServerThreadPool.java). Sockets are thus the very basis of distributed applications, the lowest level with which a programmer might have to work.

The [world wide web](https://en.wikipedia.org/wiki/World_Wide_Web) is based on three pillars: [HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol), [HTML](https://en.wikipedia.org/wiki/HTML)/[CSS](https://en.wikipedia.org/wiki/Cascading_Style_Sheets)/[Javascript](https://en.wikipedia.org/wiki/JavaScript), and [URLs](https://en.wikipedia.org/wiki/Uniform_Resource_Locator). HTTP, the Hyper Text Transfer Protocol, is a text-based protocol to query resources which is usually transmitted over TCP connections. Actually, we already provide  example implementations of both the [server](http://github.com/thomasWeise/distributedComputingExamples/tree/master/sockets/java/src/MinHTTPServer.java) ([web server](https://en.wikipedia.org/wiki/Web_server)) and [client](http://github.com/thomasWeise/distributedComputingExamples/tree/master/sockets/java/src/MinHTTPClient.java) ([web browser](https://en.wikipedia.org/wiki/Web_browser)) client side of the HTTP communication using [sockets](http://github.com/thomasWeise/distributedComputingExamples/tree/master/sockets/java) (and even a small [parallel web server](http://github.com/thomasWeise/distributedComputingExamples/tree/master/sockets/java/src/MinHTTPServerThreadPool.java). We then provide some rudimentary [examples](http://github.com/thomasWeise/distributedComputingExamples/tree/master/html/) for [HTML](http://github.com/thomasWeise/distributedComputingExamples/tree/master/html/example_pain/index.html), [CSS](http://github.com/thomasWeise/distributedComputingExamples/tree/master/html/example_css/index.html), and [JavaScript](http://github.com/thomasWeise/distributedComputingExamples/tree/master/html/example_javascript_calculator/index.html).

Implementing HTTP based on sockets is quite complex. Sockets allow us access TCP. What we would like to have is a similarly elegant API to access HTTP (the next higher level of abstraction). One such technology are [Java Servlets](https://en.wikipedia.org/wiki/Java_Servlet). Servlets are used to implement the server-side of a HTTP conversation. A servlet is a sub-class of a special Java class which implements handler methods for different HTTP interactions ("[HTTP methods](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods)"). These methods are called by a [servlet container](https://en.wikipedia.org/wiki/Web_container), the actual implementation of the server. We can therefore fully concentrate on the application logic and don't need to worry about the protocol interaction itself. We provide a wide range of examples for [Java Servlets](http://github.com/thomasWeise/distributedComputingExamples/tree/master/javaServlets/), both [deployable examples](http://github.com/thomasWeise/distributedComputingExamples/tree/master/javaServlets/examples) as well as a stand-alone [HTTP Proxy Servlet](http://github.com/thomasWeise/distributedComputingExamples/tree/master/javaServlets/proxy). So with Java Servlets, we can build server components that can dynamically interact with a HTTP client (such as a web browser). This means that we can dynamically generate contents of a web page when a browser requests them. However, building complete dynamic web sites as Java Servlets is again quite cumbersome, as servlets are Java classes while web pages are HTML, which we would then write in form of string constants to be written to the output of a Servlet.

The next higher level of abstraction are [JavaServer Pages](https://en.wikipedia.org/wiki/JavaServer_Pages) (JSPs), which allow us to write HTML pages (or other text formats) and include Java source code in it. The pages are then served again by a servlet container. Whenever a page is sent to a client, the included Java code is first executed on the server side (and may generate additional output). Upon closer inspection, we can find that JSPs are actually "special" servlets: When a JSP is accessed for the first time, the servlet container dynamically creates the source code of a corresponding Java Servlet. This servlet is compiled, loaded, and then executed to create the dynamic content of the page to be sent to the client. Everything which was "text" in JSP becomes a String inside the servlet which is written to the servlet's HTTP response. Everything which was "code" in the JSP is copied directly into the handler methods of the servlet. JSPs are a more natural way to dynamically generate text (HTML) output and serve it to a client. By now, we have a solid understanding how dynamic contents in the web can be generated, how a user can interact with a web application via web forms by using her browser, and how we can realize sessions.

While these technologies allow us to build a dynamic "outside" view of a company, the way the company presents itself in the web, we now explore the "inside" view of the distributed enterprise computing environment. Here the goal is to build an environment in which applications from different departments (financial department, human resources, asset management, ...) can be connected with each other in a future-safe, extensible way.

The first step on this road to enterprise computing are [Remote Procedure Calls](https://en.wikipedia.org/wiki/Remote_procedure_call) (RPCs), which we explore on the example of [Java Remote Method Invocation](https://en.wikipedia.org/wiki/Java_remote_method_invocation) (RMI). Our [examples](http://github.com/thomasWeise/distributedComputingExamples/tree/master/javaRMI/) show how an object of one application hosted on computer can be accessed from another program running on a another computer. This brings us already close to realizing distributed applications interconnected on a network. However, Java RMI is still a Java-specific technology and its protocol is binary. We would like to implement our distributed applications in a platform-independent way, by using very clear, well-specified, and easy-to-understand protocols.

Our pursuit of such a technology forces us to first take the de-tour of learning about the Extensible Markup Language ([XML](https://en.wikipedia.org/wiki/Xml). XML is a self-documenting format for storing complex data structures in text. It is similar to HTML, but without any pre-defined semantic or presentation. These can be specified for each application. We both look at [examples for XML documents and related standards](http://github.com/thomasWeise/distributedComputingExamples/tree/master/xml/xml) themselves as well as [examples for XML processing with Java](http://github.com/thomasWeise/distributedComputingExamples/tree/master/xml/java).

We then discuss [Web Services](https://en.wikipedia.org/wiki/Web_service). Web services are the basic foundation of many distributed enterprise computing systems and [service-oriented architectures](https://en.wikipedia.org/wiki/Service-oriented_architecture). They are invoked using the [XML](http://github.com/thomasWeise/distributedComputingExamples/tree/master/xml/)-based [SOAP](https://en.wikipedia.org/wiki/SOAP) protocol usually over [HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol). Their interface and provided functionality is described via the Web Service Description Language ([WSDL](https://en.wikipedia.org/wiki/Web_Services_Description_Language)), another XML standard. Based on what we already know, we could now send XML data to a Java Servlet via HTTP-POST, parse this data with these Java XML processing technologies, use the same technologies to generate an output XML document, and send this one back as the response of the Java Servlet. Actually, we could even use JavaServer Pages for this purpose. However, there again is a simpler way: We can build services as simple Java objects and publish them to the [Apache Axis2/Java](http://axis.apache.org/axis2/java/core/) server. The server will make them accessible via SOAP and automatically generate WSDL descriptions. These can then be used to generate proxy objects for the client side using, e.g., [Maven](http://maven.apache.org/). We investigate this technology on [several examples](http://github.com/thomasWeise/distributedComputingExamples/tree/master/webServices/).

[JSON RPC](https://en.wikipedia.org/wiki/JSON-RPC) is another remote procedure call ([RPC](https://en.wikipedia.org/wiki/Remote_procedure_call)) approach (specified [here](http://json-rpc.org/)) where the exchanged data structures are encoded in the JavaScript Object Notation ([JSON](https://en.wikipedia.org/wiki/JSON)). The data is exchanged via either [HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) or [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol). JSON RCPs are similar to web services, but designed to be more light-weighted. We again discuss several [examples](http://github.com/thomasWeise/distributedComputingExamples/tree/master/jsonRPC/).

Finally, the last tier of our lecture focuses on how the computing power of massive clusters can be utilized for large-scale scientific and engineering computations. Obviously, Web Services, Java Servlets, or even just Java and the HTTP protocol, would be the wrong technologies for that: For large-scale computations, we want to get as efficient as possible with as little overhead as possible. We want to exchange primitive data types efficiently and we want to use communication paradigms not supported by HTTP/TCP, such as broadcasts, multicasts, and asynchronous communication. For this, an implementation of the Message Passing Interface ([MPI](https://en.wikipedia.org/wiki/Message_Passing_Interface)) would be the method of choice. We explore this technology based on [several examples](http://github.com/thomasWeise/distributedComputingExamples/tree/master/mpi/) in the C programming language.

All in all, this course will give you a rough understanding of the dominant technologies in different fields of distributed computing, from dynamic websites over company-internal distributed application systems, to distributed engineering and scientific computations. Each field is explored with hands-on examples and you get to test and play with several example technologies.