La caractérisation donnée ici est tirée du chapitre 7 de ISO 7498-1. La description originelle donne en plus pour chaque couche les fonctions de manipulation de commandes ou de données significatives parmi celles décrites plus bas.
La couche « physique » est chargée de la transmission effective des signaux entre les interlocuteurs. Son service est typiquement limité à l'émission et la réception d'un bit ou d'un train de bit continu (notamment pour les supports synchrones).
La couche « liaison de données » gère les communications entre 2 machines adjacentes, directement reliées entre elles par un support physique.
La couche « réseau » gère les communications de proche en proche, généralement entre machines : routage et adressage des paquets.(cf. note ci-dessous).
La couche « transport » gère les communications de bout en bout entre processus (programmes en cours d'exécution).
La couche « session » gère la synchronisation des échanges et les «transactions», permet l'ouverture et la fermeture de session.
La couche « présentation » est chargée du codage des données applicatives, précisément de la conversion entre données manipulées au niveau applicatif et chaînes d'octets effectivement transmises.
La couche « application » est le point d'accès aux services réseaux, elle n'a pas de service propre spécifique et entrant dans la portée de la norme
Ajouter de dessin classique pilotage support
Remote procedure calls
Architectural elements involved in the XML-RPC.
RPC Web services present a distributed function (or method) call interface that is familiar to many developers. Typically, the basic unit of RPC Web services is the WSDL operation.
The first Web services tools were focused on RPC, and as a result this style is widely deployed and supported. However, it is sometimes criticised for not being loosely coupled, because it was often implemented by mapping services directly to language-specific functions or method calls. Many vendors felt this approach to be a dead end, and pushed for RPC to be disallowed in the WS-I Basic Profile.
[edit]Service-oriented architecture
Web services can also be used to implement an architecture according to Service-oriented architecture (SOA) concepts, where the basic unit of communication is a message, rather than an operation. This is often referred to as "message-oriented" services.
SOA Web services are supported by most major software vendors and industry analysts. Unlike RPC Web services, loose coupling is more likely, because the focus is on the "contract" that WSDL provides, rather than the underlying implementation details.
[edit]Representational state transfer
Finally, RESTful Web services attempt to emulate HTTP and similar protocols by constraining the interface to a set of well-known, standard operations (e.g., GET, PUT, DELETE). Here, the focus is on interacting with stateful resources, rather than messages or operations. RESTful Web services can use WSDL to describe SOAP messaging over HTTP, which defines the operations, or can be implemented as an abstraction purely on top of SOAP (e.g., WS-Transfer).
Complex Systems is a new approach to science that studies how relationships between parts give rise to the collective behaviors of a system and how the system interacts and forms relationships with its environment.
Complex Systems is a new approach to science that studies how relationships between parts give rise to the collective behaviors of a system and how the system interacts and forms relationships with its environment.
Complex Systems is a new approach to science that studies how relationships between parts give rise to the collective behaviors of a system and how the system interacts and forms relationships with its environment.
Complex Systems is a new approach to science that studies how relationships between parts give rise to the collective behaviors of a system and how the system interacts and forms relationships with its environment.
Fault-tolerance through the implicit redundancy. This is, however, an architectural issue. It is not enough to rent your computing infrastructure from Amazon, Google or Microsoft to get this benefit. You also need to implement your information system with an architectural paradigm which takes advantage from the availability of multiple servers.
Super-computing performance through parallelization. The same remark applies: it is true that new techniques for data mining or real-time event processing (two examples) may be tried successfully on the cloud through a MapReduce approach; it also requires a significant amount of work if you start from your legacy application.
Reduced costs of operation (TCO) through the use of standardized and mass-produced units. Look at the price of the TPMC according to the type of hardware and you will get the idea. I won't dwell on this, this is explained everywhere in the newspaper articles I was mentioning.
.
The risk of loosing privacy and control (cf. R. Stallman's reaction). There are many aspects, including legal and societal, to this issue. This is the part that is reasonably well covered in the papers (such as The Economist). It is clearly a valid point, but technology and service segmentation might alleviate this issue in the future. There may exist private clouds, secure clouds, encrypted clouds (where the encryption is managed by a third-party), etc.
Latency : accessing the cloud is not instantaneous. Even if the protocols were truly optimal (and they are not, web service invocation carries a significant overload), it takes some time to access to a distant data center (the light takes 10 ms to travel 3000km, and 10ms is significant for many high-performance computations or transactions). This is why MMORPGs rely on a RCA (rich client architecture – a significant part of the work is done locally).
Computational overhead: making each service invocation a web service invocation is not practical for high performance computing. There is a proper level of granularity for encapsulating a piece of computation/transaction into a cloud service. This is actually something for which there exists a significant amount of history: when companies try to develop a SOA architecture, they have to get the service granularity right. Otherwise, they "discover" that application servers cannot carry an infinite load and that they exhibit a performance overhead when compared with more traditional approaches (a RPC – remote procedure call- is more expensive than a procedure call, and a WS call is not the cheapest RPC).