Présentation générale d'une architecture orientée service :
- Définition des différents acteurs
- Notion de service
- Définition d'une plateforme SOA
- Implémentation WCF
Cette présentation donne une idée bien détaillée sur les web services. Elle présente aussi les types de web services(SOAP, REST), et enfin comment les développer dans le langage de programmation java.
Un Système de Gestion de Bases de Données Réparties est constitué d'un ensemble de processeurs autonomes «appelés sites » (stations de travail, micro-ordinateurs, …) reliés par un réseau de communication qui leur permet d'échanger des données. Un SGBDRé suppose que les données soient stockées sur au moins deux sites. Chaque site est doté de son propre SGBD.
Ce support de cours propose une vue d’ensemble sur les avantages et inconvénients de répartition de données. Aussi, il présente les différentes techniques de répartition
Présentation générale d'une architecture orientée service :
- Définition des différents acteurs
- Notion de service
- Définition d'une plateforme SOA
- Implémentation WCF
Cette présentation donne une idée bien détaillée sur les web services. Elle présente aussi les types de web services(SOAP, REST), et enfin comment les développer dans le langage de programmation java.
Un Système de Gestion de Bases de Données Réparties est constitué d'un ensemble de processeurs autonomes «appelés sites » (stations de travail, micro-ordinateurs, …) reliés par un réseau de communication qui leur permet d'échanger des données. Un SGBDRé suppose que les données soient stockées sur au moins deux sites. Chaque site est doté de son propre SGBD.
Ce support de cours propose une vue d’ensemble sur les avantages et inconvénients de répartition de données. Aussi, il présente les différentes techniques de répartition
This document discusses deployment processes and best practices. It defines deployment as the activities that make a software system available for use and involve moving approved releases to test and production environments. The document outlines deployment workflows involving development, staging, and production environments. It also discusses concepts like continuous integration, continuous delivery, continuous deployment, and DevOps practices for automating deployment processes.
Thinking BIG ou comment passer des Data aux BIG DATA!
(pour un meilleur rendu, installer la police Poiret One: http://www.1001freefonts.com/d/5561/poiret_one.zip )
Cas d'usages d'un ESB - Petals Link - 2011Petals Link
Découvrez en quelques minutes les enjeux essentiels des architectures orientées services (interopérabilité, agilité, disponibilité) et comment y répondre à l'aide d'un ESB.
Ouvrir son SI avec la trilogie Portail, SOA, BPM (Solutions Linux 2010 - cycl...Marc Dutoo
Cas client Open Wide ( http://www.openwide.fr ) : ouverture du Système d'Information d'un service public dans une démarche SOA «Libre», sur une architecture à la pointe des technologies (briques Liferay, OW2 Petals - Scarbo - Bonita, Eclipse JWT). Présenté au salon Solutions Linux 2010, dans le cadre du cycle SOA ( http://www.solutionslinux.fr/FormationsTutoriels_168_171.html ).
Le terme ‘Microservices’ fait le buzz depuis plusieurs mois déjà dans l’ingénierie logicielle. Durant cette soirée, Zenika vous propose de décrire en détail cette technique de décomposition de son système d’information.
La première partie de la soirée présente les enjeux des MicroServices et les différents cas d’utilisation.
La seconde partie aborde différents frameworks Java qui peuvent être utilisés pour la mise en place d’une architecture MicroServices.
- Graph databases like Neo4j use a graph structure with nodes and relationships to represent data. Nodes can represent entities and relationships can represent connections between nodes.
- The example database models movies, people, and their relationships. Movies and people are represented as nodes with labels. Relationships like "ACTED_IN" connect actors to movies they appeared in.
- Cypher is the query language used to interact with Neo4j. Queries can read and modify data, traverse paths in the graph, and use filters to find specific nodes/relationships.
This document provides an overview of using MongoDB with examples of common operations like inserting documents, querying, updating, and indexing. It demonstrates how to:
- Set up and connect to a MongoDB database using Docker
- Insert, find, update, and remove documents from a collection
- Query documents using equality, greater/less than, AND/OR operators
- Sort and limit output with projections
- Create indexes on fields for improved performance
This document provides instructions for using Cassandra with Docker and examples of Cassandra queries for creating and interacting with keyspaces, tables, rows, columns and different data types including sets, lists, and maps. It demonstrates how to create and query tables with a single primary key or composite primary keys, add and modify columns, insert, update, select and delete data. The document concludes with an activity to design and implement an enrollment example using Cassandra.
L'IA connaît une croissance rapide et son intégration dans le domaine éducatif soulève de nombreuses questions. Aujourd'hui, nous explorerons comment les étudiants utilisent l'IA, les perceptions des enseignants à ce sujet, et les mesures possibles pour encadrer ces usages.
Constat Actuel
L'IA est de plus en plus présente dans notre quotidien, y compris dans l'éducation. Certaines universités, comme Science Po en janvier 2023, ont interdit l'utilisation de l'IA, tandis que d'autres, comme l'Université de Prague, la considèrent comme du plagiat. Cette diversité de positions souligne la nécessité urgente d'une réponse institutionnelle pour encadrer ces usages et prévenir les risques de triche et de plagiat.
Enquête Nationale
Pour mieux comprendre ces dynamiques, une enquête nationale intitulée "L'IA dans l'enseignement" a été réalisée. Les auteurs de cette enquête sont Le Sphynx (sondage) et Compilatio (fraude académique). Elle a été diffusée dans les universités de Lyon et d'Aix-Marseille entre le 21 juin et le 15 août 2023, touchant 1242 enseignants et 4443 étudiants. Les questionnaires, conçus pour étudier les usages de l'IA et les représentations de ces usages, abordaient des thèmes comme les craintes, les opportunités et l'acceptabilité.
Résultats de l'Enquête
Les résultats montrent que 55 % des étudiants utilisent l'IA de manière occasionnelle ou fréquente, contre 34 % des enseignants. Cependant, 88 % des enseignants pensent que leurs étudiants utilisent l'IA, ce qui pourrait indiquer une surestimation des usages. Les usages identifiés incluent la recherche d'informations et la rédaction de textes, bien que ces réponses ne puissent pas être cumulées dans les choix proposés.
Analyse Critique
Une analyse plus approfondie révèle que les enseignants peinent à percevoir les bénéfices de l'IA pour l'apprentissage, contrairement aux étudiants. La question de savoir si l'IA améliore les notes sans développer les compétences reste débattue. Est-ce un dopage académique ou une opportunité pour un apprentissage plus efficace ?
Acceptabilité et Éthique
L'enquête révèle que beaucoup d'étudiants jugent acceptable d'utiliser l'IA pour rédiger leurs devoirs, et même un quart des enseignants partagent cet avis. Cela pose des questions éthiques cruciales : copier-coller est-il tricher ? Utiliser l'IA sous supervision ou pour des traductions est-il acceptable ? La réponse n'est pas simple et nécessite un débat ouvert.
Propositions et Solutions
Pour encadrer ces usages, plusieurs solutions sont proposées. Plutôt que d'interdire l'IA, il est suggéré de fixer des règles pour une utilisation responsable. Des innovations pédagogiques peuvent également être explorées, comme la création de situations de concurrence professionnelle ou l'utilisation de détecteurs d'IA.
Conclusion
En conclusion, bien que l'étude présente des limites, elle souligne un besoin urgent de régulation. Une charte institutionnelle pourrait fournir un cadre pour une utilisation éthique.
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...OCTO Technology
Par Nicolas Bordier (Consultant numérique responsable @OCTO Technology) et Alaric Rougnon-Glasson (Sustainable Tech Consultant @OCTO Technology)
Sur un exemple très concret d’audit d’éco-conception de l’outil de bilan carbone C’Bilan développé par ICDC (Caisse des dépôts et consignations) nous allons expliquer en quoi l’ACV (analyse de cycle de vie) a été déterminante pour identifier les pistes d’actions pour réduire jusqu'à 82% de l’empreinte environnementale du service.
Vidéo Youtube : https://www.youtube.com/watch?v=7R8oL2P_DkU
Compte-rendu :
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...Horgix
This is the slide deck of a talk by Alexis "Horgix" Chotard and Laurentiu Capatina presented at the MongoDB Paris User Group in June 2024 about the feedback on how PayFit move away from a monolithic hell of a self-hosted MongoDB cluster to managed alternatives. Pitch below.
March 15, 2023, 6:59 AM: a MongoDB cluster collapses. Tough luck, this cluster contains 95% of user data and is absolutely vital for even minimal operation of our application. To worsen matters, this cluster is 7 years behind on versions, is not scalable, and barely observable. Furthermore, even the data model would quickly raise eyebrows: applications communicating with each other by reading/writing in the same MongoDB documents, documents reaching the maximum limit of 16MiB with hundreds of levels of nesting, and so forth. The incident will last several days and result in the loss of many users. We've seen better scenarios.
Let's explore how PayFit found itself in this hellish situation and, more importantly, how we managed to overcome it!
On the agenda: technical stabilization, untangling data models, breaking apart a Single Point of Failure (SPOF) into several elements with a more restricted blast radius, transitioning to managed services, improving internal accesses, regaining control over risky operations, and ultimately, approaching a technical migration when it impacts all development teams.
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Laurent Speyser
(Conférence dessinée)
Vous êtes certainement à l’origine, ou impliqué, dans un changement au sein de votre organisation. Et peut être que cela ne se passe pas aussi bien qu’attendu…
Depuis plusieurs années, je fais régulièrement le constat de l’échec de l’adoption de l’Agilité, et plus globalement de grands changements, dans les organisations. Je vais tenter de vous expliquer pourquoi ils suscitent peu d'adhésion, peu d’engagement, et ils ne tiennent pas dans le temps.
Heureusement, il existe un autre chemin. Pour l'emprunter il s'agira de cultiver l'invitation, l'intelligence collective , la mécanique des jeux, les rites de passages, .... afin que l'agilité prenne racine.
Vous repartirez de cette conférence en ayant pris du recul sur le changement tel qu‘il est généralement opéré aujourd’hui, et en ayant découvert (ou redécouvert) le seul guide valable à suivre, à mon sens, pour un changement authentique, durable, et respectueux des individus! Et en bonus, 2 ou 3 trucs pratiques!
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...OCTO Technology
par Claude Camus (Coach agile d'organisation @OCTO Technology) et Gilles Masy (Organizational Coach @OCTO Technology)
Les équipes infrastructure, sécurité, production, ou cloud, doivent consacrer du temps à la modernisation de leurs outils (automatisation, cloud, etc) et de leurs pratiques (DevOps, SRE, etc). Dans le même temps, elles doivent répondre à une avalanche croissante de demandes, tout en maintenant un niveau de qualité de service optimal.
Habitué des environnements développeurs, les transformations agiles négligent les particularités des équipes OPS. Lors de ce comptoir, nous vous partagerons notre proposition de valeur de l'agilité@OPS, qui embarquera vos équipes OPS en Classe Business (Agility), et leur fera dire : "nous ne reviendrons pas en arrière".
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Chp2 - SOA
1. Institut National des Sciences Appliquées et de Technologie Tunisie
E-Services
Chapitre 2 – Architecture Orientée Services (SOA)
Dr. Lilia SFAXI
GL5 - 2013-2014
2. 1
Plan du Chapitre
Besoins de la SOA
Notion de Service
Architecture Orientée Services : Définition et Principes
Éléments de base de la SOA
SOA et Processus
3. 2
Plan
Besoins de la SOA
Notion de Service
Architecture Orientée Services : Définition et Principes
Éléments de base de la SOA
SOA et Processus
4. 3
Besoins de l’Architecture Orientée Services
Problématique d’intégration en entreprise
o
o
Les entreprises doivent s’adapter et être réactives aux variations des marchés Impact
sur les SI des entreprises
C’est l’activité qui doit piloter la technologie et non l’inverse
Prise en compte de l’évolution des besoins fonctionnels à la conception des
application
o
La technologie doit apporter la flexibilité
Éviter le décalage entre besoins métiers et leur réalisation
Besoin de réutilisation des fonctionnalités (non fournie par le modèle MVC classique)
Processus métiers de plus en plus inter-départementaux coût considérable dans
la gestion de flux entre départements
5. 4
Évolution des Architectures
Hier : Architecture en Spaghetti
Demain : Architecture Urbanisée
Organisation du SI à l’image d’une ville
Développement coûteux
Interconnexions redondantes
o
Le découper en modules autonomes
Grande complexité
o
Réutilisation et maintenance difficile
Localiser les zones d’échange
d’informations
6. 5
De plus en plus d’abstraction
Procédures et fonctions
o
Modules
o
groupes de fonctions, de méthodes et de traitement, sous forme de
bibliothèques
Objet
o
sous-programmes réalisant une action
brique de base logicielle, représentant une entité du monde physique,
encapsulant un état et des traitements
Composant
o
o
séparation des préoccupations techniques et fonctionnelles
o
élément logiciel contenant du code compilé (donc opaque)
définit une interface pour communiquer avec les autres composants, et une
interface de configuration
Service
7. 6
Plan
Besoins de la SOA
Notion de Service
Architecture Orientée Services : Définition et Principes
Éléments de base de la SOA
SOA et Processus
8. 7
Service
Périmètre fonctionnel qu’on souhaite exposer à un certain type de consommateurs
Ensemble de fonctionnalités qui ont un sens
Expose un petit nombre d’opérations offrant un traitement de bout en bout
Est implémenté par un fournisseur et utilisé par un consommateur
9. 8
Caractéristiques d’un Service
Large Granularité (coarse-grained)
o
Interface
o
Un service peut implémenter plusieurs interfaces, et aussi plusieurs services peuvent implémenter une interface commune.
Localisable
o
Les opérations proposées par un service encapsulent plusieurs fonctions et opèrent sur un périmètre de données large au
contraire de la notion de composant technique.
Avant d’appeler (bind, invoke) un service, il faudra le trouver (find).
Instance unique
o
o
À la différence des composants qui sont instanciés à la demande et peuvent avoir plusieurs instances en même temps, un
service est unique.
Un service correspond au design pattern Singleton.
Couplage faible (loosely-coupled)
o
o
Ces standards assurent le découplage, c-à-d la réduction des dépendances.
o
Les services sont connectés aux clients et autres services via des standards
Ces standards sont en général des documents XML comme dans les web services
Synchrone ou Asynchrone
10. 9
Couplage Fort vs. Couplage Faible
Couplage Fort
Agent
Accord de Prêt
Compte
Prêt
SMS Gateway
calculerRisque
vérifierSolde
créerPrêt
envoyerConfirmation
o
« Agent » est lié à « Accord de Prêt », qui est lié à « Compte »
o
« Prêt » est lié à « SMS Gateway »
Objets
11. 10
Couplage Fort vs. Couplage Faible
Processus
Métier
Couplage Faible
Processus de Prêt
Vérification de Solde
Calcul de Risque
Création de Prêt
Notification par SMS
o
Chaque entité (service) a un fonctionnement indépendant des autres
o
Le processus métier « Processus de Prêt » permet d’orchestrer les services Couplage
lâche ou faible
Services
12. 11
Types de Services
Les services de présentations ou de référencement
o
Les processus métiers
o
composés de tâches décrites et faisant appel éventuellement à d’autres services.
Les services de gestion et d’accès aux bases de données
o
vers les informations affichées et les formulaires de saisies de données.
permettent la gestion des données partagées
Les services d’intégration
o
en charge de la messagerie ou l’échange de données tant à l’intérieur que vers l’extérieur
comme la gestion des courriers électroniques
13. 12
Plan
Besoins de la SOA
Notion de Service
Architecture Orientée Services : Définition et Principes
Éléments de base de la SOA
SOA et Processus
14. 13
Architecture Orientée Services
SOA (Service Oriented Architecture)
Style d’architecture organisé à partir de services métiers communs mutualisés pour un
ensemble de lignes métiers ou d’applications.
Permet d’intégrer et de manipuler les différentes briques et composants applicatifs
d’un système informatique et de gérer les liens qu’ils entretiennent
Objectifs
o
Décomposer une fonctionnalités en un ensemble de fonctions basiques (services) fournies
par des composants
o
Décrire finement le schéma d’interaction entre ces services
15. 14
Du point de vue des acteurs…
Des services que l’entreprise
souhaite exposer à ses clients et
partenaires, ou à d’autres
parties de l’organisation
Dirigeant
Une architecture basée sur un
fournisseur, un consommateur et
une description de service
Architecte
Un style de programmation avec
ses standards, paradigmes,
technologies et outils associés
Développeur
Un intergiciel offrant des
fonctionnalités en terme
d’assemblage, d’orchestration,
de surveillance et de gestion des
services
Intégrateur
16. 15
Principes de la SOA (1/2)
Diviser pour régner
o
Alignement métier
o
Substituer la découpe strictement applicative par une structuration en composants plus
réduits et potentiellement plus simples à faire évoluer.
Construire et organiser le système à partir des réalités métiers, qui doivent se retrouver dans
ses constituants.
Neutralité technologique
o
Assurer une indépendance totale entre les interfaces et les implémentations.
o
L’élément qui utilise un service ne doit pas être contraint ni par la technologie
d’implémentation, ni par sa localisation (potentiellement distribué).
17. 16
Principes de la SOA (2/2)
Mutualisation
o
o
Favoriser la réutilisation de services métiers par plusieurs lignes métiers ou applications.
Permettre la construction de services de haut niveau par combinaison de services existants.
Automatisation des processus métier
o
Isoler la logique des processus métiers sur des composants dédiés qui prennent en charge
les enchainements de tâches et les échanges de flux d’information.
Echanges orientés Document
o
Les informations échangées par les services possèdent une structure propre, guidée par les
besoins métiers.
o
On privilégie la transmission de contenus complets et utilisables au profit d’accès direct aux
structures de type objet ou relationnel.
18. 17
Plan
Besoins de la SOA
Notion de Service
Architecture Orientée Services : Définition et Principes
Éléments de base de la SOA
SOA et Processus
19. Éléments de Base
Composant de Service
Brique de base de l’architecture, composé d’une vue externe et
interne
La vue externe ou spécification :
o
Expose la facette service proprement dite
o
Constituée :
o
d’un ensemble d’opérations de service regroupées en interfaces
appareillage pour les utiliser (types de données échangées, contrat de
service, propriétés…)
Décrite par un fichier WSDL ou équivalent
La vue interne :
o
Décrit le contenu du composant
o
Masquée aux consommateurs du composant
o
Contient des informations relatives à la logique interne (détail de
traitement ou bases de données) + références vers les services
utilisés par le composant
18
20. Éléments de Base
Bus d’Entreprise (ESB : Enterprise Service Bus)
Présence de plusieurs participants sous forme de :
o
Fournisseurs de service : composants de service, deux
familles:
o
Composants qui prennent en charge l’implémentation des
services
Composants qui délèguent son implémentation à un tiers
(mainframe, ERP, application existante)
Consommateurs de service : applications, progiciels ou
autres composants de service
ESB :
o
Colonne vertébrale reliant les participants à travers les
interfaces de service
o
Possibilité de modifier les implémentations ou de remplacer
les composants sans changer la structure du système
19
21. Éléments de Base
Contrat de Service
Détaille les conditions d’utilisation du service sous forme de:
o
Pré- et Post- conditions : Détaillent les conditions d’utilisation sur les opérations de service
o
Protocole d’utilisation: les séquences valides d’invocation de ses opérations
o
Contraintes (QoS, SLA: Service Level Agreement, sécurité, fiabilité…)
20
22. Éléments de Base
Données
Données d’échange
o
o
Informations véhiculées entre les participants à
travers l’invocation des opérations de service
TDE : Types de donnée d’échange : établissent
la sémantique, structure et format de ces
données, définis à l’aide de schémas XML ou
classes UML
Données persistantes
o
Informations contenues et gérées dans les
bases de données
o
Structurées de façon habituelle (SGBD
relationnel, par exemple)
21
23. 22
Plan
Besoins de la SOA
Notion de Service
Architecture Orientée Services : Définition et Principes
Éléments de base de la SOA
SOA et Processus
24. 23
SOA et Processus
Dans SOA, l’automatisation des processus est très importante
Définition de plusieurs notions: (on les détaillera ultérieurement)
o
o
Composition de services
o
Orchestration de services
Chorégraphie
Objectif
o
Centraliser la logique d’un processus dans un composant dédié, qui prend en charge
l’enchaînement des règles de gestion associées
26. 25
Processus Métier
Processus de bout en bout de l’entreprise
Délivre une valeur ajoutée tangible à l’extérieur par une collaboration de plusieurs
unités et acteurs
Il peut être interrompu :
o
Possède un état, qu’il peut conserver entre deux interruptions
Peut durer plusieurs jours, mois ou plus
Est transverse : entre plusieurs départements, unités, acteurs…
Peut requérir une intervention humaine dans son déroulement, ou pas.
28. 27
Sources
Cours
M. Mecella : A very short Introduction to Web Services, Université de Rome
A. Occello : Module Architecture SOA et Workflow, Polytechnique de Nice
Livre Blanc
Gilbert Raymond, SOA : Architecture Logique - Principes, structures et bonnes pratiques,
Softeam, Paris
29. 28
Références
[Casati01] F. Casati, M.C. Shan, D. Georgakopoulos (eds.): Special Issue on e-Services.
VLDB Journal, 10(1), 2001, Based on the 1st International Workshop on Technologies
for e-Services (VLDB-TES 2001)
[Mecella01] M. Mecella, B. Pernici: Designing Wrapper Components for e-Services in
Integrating Heterogeneous Systems. VLDB Journal, 10(1), 2001, Based on the 1st
International Workshop on Technologies for e-Services (VLDB-TES 2001)
[W3C04] W3C Working Group Note, Web Services Architecture Requirements, 11 Feb.
2004