Advanced Software Engineering

Transcription

1 Advanced Software Engineering Prof. J. Pasquier-Rocha

2 Presentation Professeur: Jacques Pasquier-Rocha Assistants: Patrik Fuhrer Ghita Kouadri Mostéfaoui Page web du cours: 27/10/2003

3 Organisation Le cours a lieu tous les lundis de 16h15 à 19h00 dans l auditoire RM S pendant le semestre d hiver 2003/04. Les participants doivent avoir suivi le cours de Bachelor "Méthodes orientées objet". Le cours est constitué à parts égales de cours "ex-cathedra" et d exercices / travaux pratiques. Examen Final: oral de 20 minutes en fin de semestre, en tenant compte du travail fourni.

4 Bibliographie [1] Richard Monson-Haefel, Enterprise JavaBeans, 3rd edition, O Reilly, [2] Scott W. Ambler, Tyler Jewell, Mastering Enterprise JavaBeans, 2nd edition, Wiley, [3] Floyd Marinescu, EJB Design Patterns, Wiley, 2002.

5 Plan 1. Architecture 3-Tiers / Serveurs d applications (1 cours) 2. J2EE: Vue d ensemble (1 cours) 3. Servlets, Java Server Pages 4. Programmation distribuée 5. Enterprise JavaBeans (5-6 cours) 6. Prise de recul critique (1 cours)

6 Plan 1. Architecture 3-Tiers / Serveurs d applications 2. J2EE: Vue d ensemble 3. Servlets, Java Server Pages 4. Programmation distribuée 5. Enterprise JavaBeans 6. Prise de recul critique

7 Architecture 3-Tiers / Serveurs 1. Motivation 2. CTM 3. Serveurs d applications d applications Définition Architectures (Corba,.Net, J2EE)

8 1.1 Motivation Serveurs d'applications

9 1.1 Motivation Motivation Dans un environnement de production les caractéristiques très importantes sont: Performance Dimensionnement (scalability) Tolérance aux pannes (failover) Sécurité Transaction Persistance Concurrence Distribution des objets

10 1.2 CTM Transaction Processing Monitor Systèmes à moniteur de traitement transactionnel: CICS (Customer Information Control System) de IBM, apparu en 1968 Tuxedo de BEA Les moniteurs TP sont des "systèmes d'exploitation" pour les systèmes d'entreprise. En effet, les systèmes de moniteur TP prennent en charge automatiquement l'environnement complet dans lequel s'exécute un système d'entreprise, y compris les transactions, la gestion des ressources et la tolérance aux pannes. Les moniteurs TP existent depuis longtemps (plus de 30 ans), la technologie sous-jacente est solide; c'est pourquoi ils sont utilisés aujourd'hui dans des systèmes critiques. Ils sont basés sur une architecture 3-tiers.

11 1.2 CTM Technologies ORB Négociateurs de requêtes d'objet (Objet Request Broker -ORB) Exemples: Java RMI CORBA (Common Object Request Broker Architecture) Les ORB ne sont pas des systèmes d'exploitation pour objets distribués. Elles ne sont que des dorsales de communication utilisées pour accéder et interagir avec des objets distants uniques. Elle définissent la "plomberie" entre les objets. Le développeur est responsable de l'incorporation dans les objets métier de la concurrence, des transactions, de la gestion des ressources et de la tolérance aux pannes. Ce sont des problèmes difficiles à résoudre! Les ORB ne parviennent pas à répondre à la complexité de la gestion d'un composant dans un environnement critique à fort volume, un domaine où les moniteurs TP excellent depuis toujours.

12 1.2 CTM Component Transaction Monitor (CTM) Ce terme a été introduit en 1999 par Anne Manes, pour décrire des serveurs d'applications à base d'objets distribués. Né de la convergence des technologies des moniteurs de traitement transactionnel et des technologies d'objets distribués: ces deux technologies fournissent une plateforme d'objets distribués robuste et puissante. Les CTM sont aux objets métier ce que les bases de données relationnelles sont aux données. TP CTM ORB

13 1.2 CTM Évolution des moniteurs TP Présentation Logique métier Backend simples "écran verts" ou terminaux passifs langages procéduraux applications en COBOL, PL/1, C network messaging et RPC base de données (DB2) début des moniteurs TP (1968) interfaces graphiques ou web sophistiquées langages orientés objet objets métier en Java, Smalltalk, C++ RMI (Java RMI ou CORBA) Avantages: plus souples, évolutifs et réutilisables base de données relationnelles ou d'un autre type CTM (aujourd'hui)

14 1.2 CTM Apparition des CTMs En 1996, Microsoft a été le premier fournisseur à livrer un CTM: appelé à l'origine MTS (Microsoft Transaction Server), il a été ensuite renommé COM+. COM+ est basé sur COM (Component Object Model), modèle de composant côté serveur. Pour les accès distribués, les clients COM+ utilisent DCOM (Distributed COM). Récemment COM+ a été intégré au nouveau framework.net de Microsoft..NET n'est pas un standard ouvert, et les services COM+ du framework.net sont un CTM spécifique à Microsoft. Les CTM non-microsoft tardaient à faire leur apparition car l'omg (Object Management Group) devait d'abord définir un modèle de composants côté serveur adapté à CORBA.

15 1.2 CTM Apparition des CTMs (2) En 1997, Sun Microsystems a développé la norme la plus prometteuse pour les composant côté serveur: les Enterprise JavaBeans. Cette norme a été acceptée par de nombreux fournisseurs, contrairement aux propositions de l'omg qui essayait de normaliser des fonctionnalités de bas niveau comme la sécurité et les transactions, ce qui nécessitait la réécriture de produits comme Tuxedo et CICS. Les EJB contournaient le problème en disant que la façon d'implémenter les services de bas niveau n'était pas importante; l'important était que toutes les fonctionnalités soient appliquées aux composants de façon conforme aux spécifications. La spécification a été finalisée et publiée: -1998: EJB : EJB EJB EJB 2.1???? EJB 3.0 Les fonctionnalités de base d'un CTM sont les objets distribués, une infrastructure qui inclut la gestion des transactions et d'autres services, et un modèle de composants côté serveur. Les serveurs d'application proposent entre autres, un CTM.

16 1.2 CTM Modèle de composant Comment coopère un composant Ce que fournit le composant (entrées) composantes, interfaces, opérations, propriétés Ce qu'utilise le composant (dépendances) composition et références aux autres composants Modes de communication des connecteurs (synchrone, asynchrone, flots) Propriétés configurables du composant Contraintes techniques (QoS) Middleware: placement, sécurité, transaction Internes: cycle de vie, persistance Implantation: OS, bibliothèques, version

17 1.3 Serveurs d'application Serveur d'application Définition: An application server is a component-based product that resides in the middle-tier of a server centric architecture. It provides middleware services for security and state maintenance, along with data access and persistence. Conforme à un modèle Gère le cycle de vie des composants Optimise les ressources physiques Offre des services: Communications Sécurité Transactions Administration

18 1.3 Serveurs d'application Division des responsabilités Le fournisseur de composants Produit des composants métier L'assembleur d'application Assemble plusieurs composants Le fournisseur de serveur d'application Fournit l'environnement d'exécution pour des composants Le déployeur (installateur) L'administrateur (droits d'accès, )

19 1.3 Serveurs d'application Division des responsabilités (2)

20 1.3 Serveurs d'application When an application server should be used You should consider an application server when you have a need for: Integration with existing systems and databases Web site support Secondary reasons to use application servers derive from the primary reasons. A few secondary reasons are: E-Commerce Web-integrated collaboration Component re-use One way to look at application servers is that they are a formalization of a solution to a problem that has been around for a long time. That problem can be characterized as a need to create an integrated presentation and processing environment for existing systems and databases. The presentation has pretty much been decided with browsers now being the dominant interface. This is why you usually see a Web server paired with or included in an application server. The integrated processing has been moving towards components for some time. Application servers provide containers for such components along with application program interfaces (APIs) to support the components. These APIs are to the existing systems and databases (e.g. JDBC).

21 1.3 Serveurs d'application Architectures proposées OMG CORBA Microsoft.NET Sun J2EE

22 1.3 Serveurs d'application CORBA Standard pour communication à distance Applications hétérogènes Pas de composants standardisés Défini par Object Management Group (OMG) Organisme indépendant Plus ancien que J2EE et.net

23 1.3 Serveurs d'application Microsoft.NET Architecture à composants distribués Différents langages de programmation mais avec une nette préférence pour C# et VB Microsoft le seul fournisseur de l'environnement complet Implantation Open Source partielle (Mono) Tendance au "Tout Microsoft" Récent Interopérable avec CORBA depuis peu

24 1.3 Serveurs d'application Sun J2EE What is J2EE? Java 2 Platform, Enterprise Edition (J2EE) is a set of coordinated specifications and practices that together enable solutions for developing, deploying, and managing multi-tier server-centric applications. Building on the Java 2 Platform, Standard Edition (J2SE), J2EE adds the capabilities necessary to provide a complete, stable, secure, and fast Java platform to the enterprise level. It provides value by significantly reducing the cost and complexity of developing and deploying multi-tier solutions, resulting in services that can be rapidly deployed and easily enhanced.

25 1.3 Serveurs d'application Sun J2EE Architecture à composants distribués Java Défini par Sun avec participation d'autres (Java Community Process) Implantations de référence Interopérable avec CORBA

26 1.3 Serveurs d'application Serveurs d'applications Java Java application servers are based on the Java 2 Platform, Enterprise Edition (J2EE ). J2EE uses a multi-tier distributed model. This model generally includes a Client Tier, a Middle Tier, and an EIS (Enterprise Information System) Tier. The Client Tier can be one or more applications or browsers. The J2EE Platform is in the Middle Tier and consists of a Web Server and an EJB Server. These servers are also called "containers." There can be additional sub-tiers in the middle tier. The Enterprise Information System (EIS) tier has the existing applications, files, and databases. For the storage of business data, the J2EE platform requires a database that is accessible through the JDBC API. The database may be accessible from web components, enterprise beans, and application client components.

27 1.3 Serveurs d'application Serveurs d'applications Java (2) Image tirée de Image tirée de "The J2EE 1.4 Tutorial" de Sun

28 1.3 Serveurs d'application The J2EE application model Image tirée de Sun (

29 1.3 Serveurs d'application Implantations de J2EE JBoss (open source) IBM Websphere BEA WebLogic JoNaS (open source) OpenEJB (open source) Borland AppServer

30 1.3 Serveurs d'application Comparaison J2EE vs.net Capacités très similaires.net: un seul fournisseur Microsoft J2EE: un seul langage Java J2EE plus ouvert que.net Meilleurs outils de développement pour.net