More documentation about the logic of this course

Author: Thomas Weise

README.md

@@ -47,7 +47,19 @@ The [world wide web](https://en.wikipedia.org/wiki/World_Wide_Web) is based on t
 
 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"). 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.
+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/).
+
+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.
 
 
 ## 2. Software Requirements

webServices/README.md

@@ -110,7 +110,7 @@ Now you can build the server projects, i.e., generate an [`aar`](http://axis.apa
 13. The build will start, you will see its status output in the console window.
 14. The folder `target` will contain a file `calculatorServer.aar` after the build. This is the deployable archive with our web service.
 
-##### 2.3.2. Bulding a Client (for using a Web Service) in Eclipse
+##### 2.3.2. Building a Client (for using a Web Service) in Eclipse
 
 Now you can actually build the client projects, i.e., generate the normal [`jar`](https://en.wikipedia.org/wiki/JAR_%28file_format%29) which you can directly execute via `java -jar ...`. Please notice that for doing this, you must have the web service running for this build procedure: