Infrastructure

Roles in data exchange

UNITED-PAGES is a web-service for the exchange of structured data from various application domains.

Basically, four different roles can be distinguished in service-oriented data exchange (participants can take over several roles):

  • Data-Producer
    originator/owner of data
  • Data-Consumer
    recipient/buyer of data
  • Service-Provider
    provider of infrastructure/webserver
  • Software-Supplier
    developer/publisher of required software/integration

UNITED-PAGES is an evolutionary enhancement of well-established Internet concepts and technologies.

Concept

Data-as-a-Service (DaaS)

DaaS - Weather Forecast

Data is increasingly seen as an asset per se and is often referred to as the currency of the 21st century.

There is a growing market in which data is collected and offered to customers as a service (e. g. stock prices, geographical data, weather forecasts). Often a DaaS provider also acts in the role of a producer, i. e. he generates the data on his own. Sometimes the provider also offers its own application for (graphical) access, but the typical business model is to sell the data accessible via an API.

A consumer can integrate data from different providers into his own applications, e. g. display on his own websites or start further analysis.

Web 2.0

Web 2.0

A significant characteristic of Web2. 0 is that users in their role as consumers not only have read access to external content, but in their role as producers they also make data available to others. The term Prosumer has been established for this. A distinction between business- and customer-users is considered obsolete.

Well-known platforms exist especially in the area of social media (e.g. Facebook), marketplaces (e.g. Ebay) and websites based on the wiki principle (e.g. Wikipedia). .

A characteristic feature of Web 2. 0 platforms is that corresponding applications for Prosumers are provided by the respective provider (e.g. Facebook app for accessing Facebook data).

Data-as-a-Service 2.0

DaaS 2.0

Data-as-a-Service 2.0 is a new word creation which stands for the fact that users act as Prosumers in the style of Web 2.0, but in the style of DaaS they are not dependent on applications of certain platforms (e.g. if users post social media data with a DaaS 2.0 provider, Facebook would only offer one of many possible applications to display this data).

DaaS 2.0 specifies no application at all. Bundling data and software often tenders to encourage vendor lock-in i. e. makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs. Lock-in costs that create barriers to market entry may result in antitrust action against a monopoly.

Daas 2.0 requires standardized access methods and data structures as well as a cross-application data protection concept.

Daas 2.0 is a solution for once-only-data. Instead of spreading redundant data over 'the web' the Producer keeps full control on his current data by defining access rights. The Consumer typically only stores a reference (e.g. URL) and there is no need for propagation when the data was changed.

Since also 'normal' Internet users are addressed, simple administration and use play a prominent role for a broad acceptance.

There are different kinds of Data-Producers for DaaS 2.0

  • Data-Proxy: an (existing) application that uses a DaaS 2.0 as Data-Proxy to supply internal data without taking the risk by allowing direct access e.g. a Scheduling-Manager of a doctor's practice enables a patient's App restricted access on relevant data via a DaaS 2.0
  • Portal/App; a person that supplies data that is manually maintained e.g. address-data from an Addressbook-App
  • Crawling: a (server-)software that converts (free) content that can be already found in the internet e.g. the current weather data from webcams. Content-Conversion opens a broad market, since it dis-burdens developers from repeated adaption of non-standardized interfaces

Technology

Email

Email

Email is still the most important service of the internet (e.g. 86% of the germans are using Email). Furthermore email-addresses are used for authentication/login (e.g. Paypal, WeTransfer).

The worldwide success of Email is based on it's provider-independence (in contrast to proprietary messengers like WhatsApp, WeChat, ...) and it's genius syntactical address-format, that is practical for humans and machines. In contrast to a mobile-phone number, an email-address is easy to keep in mind and typically long-lasting data.

The email-protocol-standards guarantee the exchange of emails between different providers(SMTP) and the possibility to request emails several times from different personal devices(IMAP).

RESTful Webservice

RESTful Webservice

Web services are services on the web with which data can be exchanged via API. These data can be of different formats. The most common formats are XML (Extensible Markup Language) and JSON (JavaScript Object Notation). The common architectural styles for creating Web services are SOAP(originally for Simple Object Access Protocol) and REST(Representational State Transfer). Both have demonstrated fast performance, reliability, and the ability to grow by reusing components. REST in particular is suitable for large applications with an unknown number of users and objects.

Not least because a REST-based implementation is simple compared to SOAP, and because REST provides an effective way to interact with lightweight clients such as smartphones, REST (together with JSON) is gaining paramount importance.

A client can access a resource via the unique URI and gets back a representation of the resource. With each new resource representation the client transfers its state. This technique is not suitable for real-time capable systems, but it is not a problem for internet applications, which have to expect a higher delay time anyway.

REST typically uses the HTTP protocol, which is usually not blocked by firewalls. The methods are essentially limited to the standard HTTP operators GET, PUT, POST, DELETE and HEAD. Simple interfaces are characteristic of a loosely coupled architecture and public interfaces are an additional way of preventing vendor lock-in.

The essential characteristic of RESTful Webservices is HATEOS - Hypermedia As The Engine Of Application State. This expresses the fact that the resources are networked with each other - similar to web pages - via hyperlinks. The World Wide Web itself is a gigantic REST application.

Cloud Computing

Cloud-Stack

The 'classic' cloud stack comprises three levels that build on each other:

  • IaaS - Infrastructure-as-a-Service
    the basic level of cloud computing is Infrastructure-as-a-Service. Here, hardware resources are leased in a virtualized form that can be configured as needed (storage space, processors). Customers primarily expect cost advantages from a virtual data center
  • PaaS - Platform-as-a-Service
    the PaaS-provider provides not only the infrastructure but also middleware (e.g. Java runtime, .NET runtime), database and further services (e.g. billing, application control) through APIs
  • SaaS - Software-as-a-Service
    SaaS is a licensing and delivery model in which on-demand-software is licensed on a subscription basis and is centrally hosted

UNITED-PAGES

UNITED-PAGES

UNITED-PAGES specifies an implementation of Data-as-a-Service 2.0. Technologically speaking, UNITED-PAGES is a RESTful web service that takes over the successful concepts of email.

The implementation offers a lot of advantages for a wide variety of customer- and business-applications. The characteristic issues are:

  • URL address format
    The address-format of UNITED-PAGES is a combination of email-addresses (RFC5322) and URL-Syntax(RFC1738). UNITED-PAGES can be put on market as ‚Add-on‘ for Email and therefore has an extraordinary target group.
  • provider independence
    The PRODUCER can transfer all his UNITs to another WEBSERVER of another PROVIDER at any time. This was intended from the ‘founding fathers’ of the worldwide web – in contrast to the existing data-monopoles (Google, Facebook, Amazon,...). Generally, the WEBSERVERs of different PROVIDERs ‘only’ differ regarding reliability, availability, performance, charges and usability (only the domain
    united-pages.com that is owned by the company UNITED PAGES(UG) provides a few exclusive features). As a result, a world-wide-webservice that is implemented by an increasing number of different PROVIDERs will evolve.
  • standardized resource formats
    Each UNIT is a representation of structured data that is stored on a WEBSERVER (typically, but not mandatory in a database). The specification comprises several types of data for different application domains (address/contact, calendar/scheduling, device/IoT, weather, encryption, ...). There is no need for a data description that has to be evaluated in the course of a data exchange (e.g. XSD).
  • generic interaction
    Each UNIT is identified by a URI(e.g. unit:adr/john.doe@goohoo.com) that can be mapped to a WEBSERVER-URL (e.g. https://api.goohoo.up/unit/adr/joh.doe/goohoo.com). The UP-API specifies webservice-requests to create/update(HTTP-Put), read(HTTP-Get) and delete(HTTP-Delete) UNITs. The access is uniform/generic, i.e. independent of the WEBSERVER where a UNIT is stored
  • inherent encryption / security by design
    The owner of a UNIT can individually determine who (specified by Email-Addresses) has read/write-access rights on which values. For implementation of privacy an inherent (hybrid) encryption procedure based on Encryption-UNITs is specified i.e. there is no other technology of another system required.

UNITED PAGES is guided by the following 'philosophy':

  • data-structures, not algorithms are central to programming
    the specification of different data-structures for different customer and business use cases lead to a multi-purpose service - in contrast to isolated proprietary applications
  • do one thing and do it well
    as a microservice that provides a definite functionality via a lightweight-protocol-API it can be easily coupled to existing applications
  • keep it simple and smart (KISS)
    the KISS principle states that most systems work best if they are kept simple rather than made complicated. UNITED-PAGES regards KISS for implementation/integration, administration and security. The KISS-principle refers to the requirements for the implementation of a compliant webserver, the integration in existing applications and the administration tasks for users. The simplicity of the UP-API and the inherent security concepts are benefits for DEVELOPERs that are implementing new APPLICATIONs or integrate additional features in existing APPLICATIONs. PROVIDERs may join at any time, mainly by installation of a WEBSERVER that is compliant with the UP-API. Low initial thresholds for USERs(no further registration) and ease of use(well-known internet-formats) are decisive for the level of utilization.

UNITED-PAGES is related with Cloud-Computing:

  • Iaas may be used to host a UNITED-PAGES Webserver
  • Paas may be used to develop a UNITED-PAGES Webserver
  • SaaS applications may use UNITED-PAGES
  • Daas2.0 could be a defined as a new separate Cloud-Category