Some time ago, I decided to go over some key technologies that exist in the digital learning field. Being a part of the wider ecosystem, working mainly with the information management part, I felt that it would be nice to structure some background knowledge on the tools and software used within the digital learning domain.
During my search and my effort to document the technologies (see previous posts, post1, post2, post3), I decided to make this a bit more generic and take a look at the web services and some of the things that surround them, in a domain-agnostic manner (as much as possible at least). These things are all around us, no matter the domain in which we apply them, so I decided to create another blog post, of a more generic nature that may also be useful to someone out there. Note to readers: This is by no means a technically-sound piece, but more of a collection of the author, based on an extended web search. So, proceed at your own risk!
To begin our story, we start with the basic OSI Conceptual Model that describes seven layers of the communication functions of a telecommunication or computing system. This is (maybe) too technical of a discussion, but offering an overview and some examples of each layer, will allow us to identify the part of this that concerns us. I will ignore the Physical and Data Link layers and go into the Network layer just to note that this include the IPv4 and IPv6 that you may have heard of. These are the protocols that provide an identification and location system for computers on networks and routes traffic across the Internet. Then, on the Transport layer, you have TCP that provides reliable, ordered, and error-checked delivery of a stream of octets between applications running on hosts communicating over an IP network. Then, on the Session layer, you have (among others) HTTP that is an application protocol used to transfer data over TCP/IP.
On the next layer, the Presentation one, you have the specifications such as HTML, JSON, XML, as well as the formats such as GIF, JPEG, etc., that are used to translate the data transferred between the networking services and the application. And finally, on the Application level, you have high-level APIs used to express a software component in terms of its operations, inputs, outputs, and underlying types, defining functionalities. Again, all the aforementioned are kind of too technical, but it’s a way to put some puzzle pieces in place before we move on to Web services.
Now, a Web service is a service offered by one electronic device (server) to another (client), based on the Client-Server model. For this offering or a server to a client to be communicated efficiently, we need the structure that was explained through the OSI Concept Model above. A Web service can contain more than one services, built as a discrete piece of code (following SOA). The exchange of messages between Client-Server, can be facilitated through the use of either SOAP messages (in XML) or REST syntax (in JSON) with the respective AJAX and AJAJ web development techniques.
Now, watch out for the distinction between a Web service and a Web application. The easiest one I found online that helped my untangle my head, was that Web services are intended to talk to other Web services or Web application whereas Web application usually interacts with users. A Web application usually has a front-end that helps the user interact with it and it’s also possible that it uses data from multiple Web services to achieve its purpose (btw, a type of a web app that is kind of popular right now, is a Rich Internet Application).
REST is the newer alternative to SOAP, though an architectural style and not a protocol, used to allow web services to exchange structured information between them. The systems conforming to the constraints of REST are called RESTful and they usually communicate over HTTP, use URIs to identify resources and also utilize XML and JSON to exchange data. REST abides to the programming paradigm of ROA. And then of course you have WOA that extends the concept of SOA in web applications. It was too difficult for me to follow, so if you want more, check out this article. On another note about REST, apparently, the web development techniques used in this case are called AJAJ, denoting the use of JSON formatted data and not XML (although this is not consistent in all sources I retrieved). Finally, the functionality of Web services that use REST is described through WADL.
Having all this information figured out (?), I wanted to organize these concepts and I found this nice web service technology stack, explained by the figure below. Looking at the layers of Web services based on what we discussed, we have HTTP, FTP, SMTP at the Service Transport layer, and the SOAP and XML (or REST and JSON) on the messaging layer. Then, the services are described in the Service Description layer where you get your WSDL (or WADL) and then there’s the layer of Service Discovery where UDDI is found, which is an XML protocol that includes a registry by which businesses worldwide can list themselves as well as a mechanism that registers and locates web service applications. On top of those there’s the Quality of Service Layer and then there’s the layer of Business Processes. I will leave the last two layers aside for the time being.
Then you have the concept of an API which is kind of a complicated one. Generally speaking, an API expresses a software component in terms of its operations, inputs, outputs, and underlying types, defining functionalities that are independent of their respective implementations. A good API makes it easier to develop a program by providing all the building blocks, which are then put together by the programmer.
An API may be for a web-based system, operating system, or database system. It can be an API for procedural languages or an API for object-oriented languages. Overall, there are lots of different APIs that can either be internal to allow for different services within an application to communicate, or external, that provide facilities to develop applications for a system using a given programming language. As an example, a programmer who develops apps for Android may use an Android API to interact with hardware, like the front camera of an Android-based device.
APIs often come in the form of a library that includes specifications for routines, data structures, object classes, and variables. In other cases, like SOAP and REST services, an API is simply a specification of remote calls exposed to the API consumers. It is usually a set of HTTP request messages, along with a definition of the structure of response messages, in either XML or JSON. So, in our case, we are talking about APIs for Web services.
Moving away from the specifics for a while, there’s the Semantic Web extension, an extension of the Web through standards by the World Wide Web Consortium (W3C). These standards promote common data formats and exchange protocols on the Web, most fundamentally the Resource Description Framework (RDF). The term was coined by Tim Berners-Lee for a web of data that can be processed by machines. While its critics have questioned its feasibility, proponents argue that applications in industry, biology and human sciences research have already proven the validity of the original concept.
RDF is used to describe, among others, resources that are exchanged between Web services. The resources are described using statements in the form of triples (subject-predicate-oblect). SPARQL is a query language for RDF that is able to retrieve and manipulate data stored in RDF format. In cases when data are stored in traditional DBMS, the respective language that can be used to retrieve data, is SQL. The Semantic Web stack below, shows the components of the Semantic Web.
The Semantic Web stack introduces a couple more interesting things to talk about, like the RDF Schema, providing basic elements for the description of ontologies, otherwise called RDF vocabularies, intended to structure RDF resources. It also involves Simple Knowledge Organization Systems (SKOS) which is a W3C recommendation designed for representation of thesauri, classification schemes, taxonomies, subject-heading systems, or any other type of structured controlled vocabulary. It also introduces the Web Ontology Language (OWL), which is a family of knowledge representation languages for authoring ontologies and the Rule Interchange Format (RIF), which is a group of dialects that allows for the exchange of rules between existing systems.
Looking at web applications again, when building one, the most prevalent architecture that can be used is the Multitier Architecture that is a client–server architecture in which presentation, application processing, and data management functions are physically separated. The most widespread use of multitier architecture is the three-tier architecture. In this architecture, the user interface (presentation tier), the functional process logic (logic tier) and the computer data storage and data access (data tier) are developed and maintained as separate modules, most often on separate platforms.
- Presentation tier: This is the top level of the application which is actually what the user accesses as a web page or a GUI. It clarifies the required input from the user and translates the outputs back to him in a meaningful way.
- Application tier (logic): This tier, takes the input from the user and processes them, making logical decisions and performing calculations. It sends requests to the Data tier and receives results which in turn are passed on to the Presentation tier.
- Data tier: This tier stores and retrieves information from a database or a file system. Data that are requested by the Application tier are passed on to it where calculations take place and the result is the shown to the user in the Presentation tier.
In the web development field, the Application tier holds an application server which is a software framework that provides both facilities to create web applications and a server environment to run them. Application servers can be developed using Ruby on Rails (web app framework), Java EE (platform), ASP.NET (web app framework), PHP (language), ColdFusion (platform), Perl (language) and Python (language).
Finally, for the Data tier, some well-known DBMSs include MySQL, PostgreSQL, Microsoft SQL Server, Oracle, Sybase, SAP HANA, and IBM DB2. On the other hand, when it comes to document-oriented databases that come in handy when we talk about learning resources (designed for storing, retrieving, and managing document-oriented information, also known as semi-structured data), some of the prevalent solutions include Elasticsearch, Apache SOLR and MongoDB.
I think that I will stop putting things into my basket right here for now. Following a path the started from the OSI Model, I followed link after link to reach the Multitier Architecture and I think that more or less, a structure has been set. I am not sure about the concept map that follows, or how helpful it can be, but as always, I would encourage comments that would help me improve it.