FR2889325A1 - Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme - Google Patents
Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme Download PDFInfo
- Publication number
- FR2889325A1 FR2889325A1 FR0507950A FR0507950A FR2889325A1 FR 2889325 A1 FR2889325 A1 FR 2889325A1 FR 0507950 A FR0507950 A FR 0507950A FR 0507950 A FR0507950 A FR 0507950A FR 2889325 A1 FR2889325 A1 FR 2889325A1
- Authority
- FR
- France
- Prior art keywords
- components
- component
- container
- metaprogram
- architecture
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
La présente invention se rapporte à une architecture à composants logiciels pour les applications à plate-forme d'exécution donnant accès au niveau métaprogramme, et en particulier pour le développement et l'exécution d'interfaces homme-machine, et elle est caractérisée en ce qu'elle est une architecture à composants (2, 3) définissant explicitement toutes les caractéristiques des composants, sans pratiquement intervenir sur le code définissant ces composants, gérant les composants pendant leur exécution, et leur fournissant des services techniques, et qu'elle comporte un conteneur générique (1) accueillant d'une part des composants (2) dont la définition découle des spécifications du cahier des charges de l'application à réaliser et dépend du domaine d'utilisation de l'application, ce conteneur accueillant d'autre part des services techniques fournis (3).
Description
ARCHITECTURE A COMPOSANTS LOGICIELS POUR LES
APPLICATIONS A PLATE-FORME D'EXECUTION DONNANT ACCES
AU NIVEAU METAPROGRAMME
La présente invention se rapporte à une architecture à composants logiciels pour les applications à plate-forme d'exécution donnant accès au niveau métaprogramme, et en particulier pour le développement et l'exécution d'interfaces homme-machine (IHM ou HCI en anglais: Human Computer Interface ).
Le développement d'applications IHM rencontre des problèmes de natures différentes: - les problèmes fonctionnels (qui répondent aux besoins opérationnels du client) - les problèmes techniques (qui répondent aux besoins non fonctionnels du client) Le développeur doit fournir des solutions à tous ces problèmes. Ces solutions sont habituellement imbriquées. Cette imbrication ne permet pas une maintenance, une évolution et une réutilisation faciles. Les évolutions fonctionnelles demandées par le client sont plus difficiles à prendre en compte. Il est également très difficile de capitaliser des solutions techniques séparément des fonctionnalités (spécifiques de chaque client).
Le développeur ne peut pas se concentrer sur la valeur ajoutée du développement que sont les fonctionnalités pour le client. De plus, le développeur doit structurer son application en choisissant une architecture.
Une architecture à composants propose une décomposition en éléments (composants) faiblement couplés (avec le minimum possible d'interdépendance entre eux). Cette architecture à composants est régulière et est applicable à l'ensemble de l'application. Ces composants étant faiblement couplés, leur maintenance, leur évolution et leur réutilisation en sont plus faciles.
Ces composants ayant une structure régulière, ils sont gérés de façon générique par un gestionnaire de composants (un conteneur, "container" en anglais). Ce conteneur apporte des solutions techniques aux problèmes non fonctionnels de l'application. Ces solutions techniques sont capitalisées séparément des fonctionnalités et disponibles pour toutes les applications d'IHM. Le développeur peut alors plus facilement se concentrer sur les besoins fonctionnels, indépendamment des besoins techniques.
Aujourd'hui, des architectures à composants sont proposées par des standards (JavaBeans, Enterprise JavaBeans- EJB, CORBA Component ModelCCM) et des COTS (Component Object Model-COM, SpringFramework, etc.). Dans le cadre d'une architecture multi-niveaux (Figure 1), ces architectures se concentrent sur le niveau métier, peu concernent le niveau présentation.
Le niveau présentation peut se présenter sous deux formes différentes: clients lourds (application IHM à part entière à déployer sur 15 le poste client avant utilisation) - clients légers (seul un navigateur Web est déployé sur le poste client).
Les architectures à composants sont essentiellement proposées pour les clients légers (Java Server Page-JSP, Active Server 20 Page-ASP, etc.).
Pour les clients lourds, les architectures connues à composants ne proposent qu'un sous-ensemble de la totalité des caractéristiques nécessaires à la définition complète d'un composant, et qui constituent un modèle de composant. Le modèle de composant au sens de la présente invention doit comporter au moins les définitions suivantes: - définition explicite des services rendus et utilisés par le composant - définition explicite des événements produits et consommés par le composant définition explicite des paramètres du composant - définition explicite du type du composant.
Ces caractéristiques, si elles étaient toutes présentes dans une architecture permettraient de séparer clairement l'interface du composant de son implémentation. Elles permettraient donc de fournir plusieurs implémentations pour une même interface.
De plus, la majorité des modèles de composants connus imposent une forme particulière: ces modèles de composants sont très intrusifs. Les classes d'analyse (résultant de l'analyse des spécifications fonctionnelles de l'application) doivent être profondément transformées pour se conformer au moule de l'architecture à composants du standard ou du COTS. L'objectif actuel de l'industrie informatique est d'atteindre la transparence totale pour les modèles de composants: les classes d'analyse ne seraient alors pas transformées pour être accueillies par le conteneur.
Par ailleurs, les architectures actuelles de composants ne proposent qu'un sous-ensemble des capacités techniques nécessaires: - les services sont uniquement en mode synchrone, - les événements sont uniquement en "push" asynchrone, - les données des services et des événements sont uniquement définies par valeurs (par copie) ou par référence sur la base du déploiement (les données sont définies par valeur uniquement dans le cas d'un accès distant réseau).
Les capacités techniques nécessaires sont présentes lorsque: - les services peuvent être utilisés de manière synchrones ou asynchrones, - les événements peuvent être publiés en "push" ou en "pull", de manière synchrone ou asynchrone, - les données des services et des événements sont transmises par valeur ou par référence indépendamment du 25 déploiement et de l'accès réseau.
La présente invention a pour objet une architecture à composants logiciels pour les applications à plate-forme d'exécution donnant accès au niveau métaprogramme, et en particulier pour le développement et l'exécution d'interfaces homme-machine dans le cadre de clients lourds, qui soit complète et transparente, et elle a également pour objet une interface homme-machine comportant une telle architecture.
La présente invention a également pour objet un procédé de mise en communication de composants logiciels pour une application à plate-forme d'exécution donnant accès au niveau métaprogramme, dans une architecture du type précité, procédé ne produisant pratiquement pas d'intrusion dans le code des composants, les contraintes techniques étant réduites à leur plus simple expression.
L'architecture à composants conforme à l'invention est une architecture à composants définissant explicitement toutes les caractéristiques des composants, sans pratiquement intervenir sur le code définissant ces composants, gérant les composants pendant leur exécution, et leur fournissant des services techniques, et elle comporte un conteneur générique accueillant d'une part des composants dont la définition découle des spécifications du cahier des charges de l'application à réaliser et dépend du domaine d'utilisation de l'application, ce conteneur accueillant d'autre part des services techniques fournis.
Le procédé de l'invention est caractérisé en ce que le conteneur détermine automatiquement à l'exécution les caractéristiques des composants et la description des services techniques fournis par interrogation via le métaprogramme des composants et des services fournis.
Selon un autre aspect du procédé de l'invention, les services techniques fournis sont mis à disposition des composants par un morceau de code directement exécutable généré par le conteneur. De façon avantageuse, le morceau de code assure la jonction entre deux composants quelconques.
La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non 25 limitatif et illustré par le dessin annexé, sur lequel: - la figure 1, déjà mentionnée ci-dessus, est un bloc-diagramme simplifié d'une architecture à composants logiciels pour le développement et l'exécution d'interfaces homme-machine aussi bien dans le cadre de clients lourds que de clients légers, architecture à laquelle peut s'appliquer l'invention, la figure 2 est un bloc-diagramme simplifié de l'architecture à composants conforme à l'invention, avec le conteneur, les composants applicatifs accueillis, et les services techniques fournis par le conteneur et disponibles pour tous les composants, la figure 3 est un bloc-diagramme explicitant des détails de fonctionnement de l'architecture de la figure 2, - les figures 4 à 8 sont des diagrammes d'exemples d'implémentations de composants, conformément à l'invention.
La présente invention est décrite en détail ci-dessous en référence à une interface homme-machine, mais il est bien entendu qu'elle n'est pas limitée à ce seul exemple, et qu'elle peut être mise en oeuvre pour toutes autres applications comportant une plate-forme d'exécution permettant l'accès au niveau métaprogramme, c'est-à-dire des applications mettant en oeuvre un langage de programmation qui fournit une définition objet de lui-même.
On a schématiquement représenté en figure 1 les trois principaux niveaux d'une architecture à composants logiciels pour le développement et l'exécution d'interfaces homme-machine. Ces trois niveaux sont: le niveau données (mettant en oeuvre un standard tel que EJB), le niveau métier (pouvant mettre en oeuvre des standards tels que EJB session, CCM, COM, Spring) et le niveau présentation, qui est un poste de travail. Si ce poste est celui de clients lourds, il fonctionne généralement sous JavaBeans, alors que pour les clients légers, il peut fonctionner sous JSP ou ASP par exemple.
L'architecture à composants logiciels représentée en figure 2 comporte essentiellement un conteneur générique 1 accueillant d'une part des composants 2 dont la définition découle des spécifications du cahier des charges de l'application à réaliser et dépend du domaine d'utilisation de cette application. Le conteneur 1 accueille d'autre part des services fournis tels que ceux cités ci-dessous.
Le conteneur a en charge la gestion du cycle de vie d'exécution des composants. Il les active, les supprime, assure la mise en communication entre eux, et les connecte aux services techniques dont ils ont besoin, par exemple en fonction de la qualité de service requise, qui peut être évolutive.
Les composants accueillis sont les composants développés dans le cadre d'une application spécifique. Ils expriment d'une manière compréhensible par le conteneur la nature des services techniques dont ils souhaitent bénéficier. Le conteneur interprète ces expressions de besoins et appelle les services techniques désirés à la place de ces composants, pour leur bénéfice, et les met en relation avec les composants demandeurs.
Les services techniques sont des composants utilisés par le conteneur pour prendre en charge les capacités non fonctionnelles, tels 10 que: - la persistance des paramètres des composants - la propagation d'événements entre composants (suivant les modes "push" ou "pull") - les traces des entrées / sorties des composants - l'asynchronisme des entrées / sorties des composants - la communication distante (réseau) entre les composants L'architecture de l'invention définit les principes de développement d'une application à base de composants par spécification de composants compatible d'un processus centré sur le modèle UML ("model driven" en anglais).
Sur le diagramme de la figure 3, qui représente partiellement une interface d'un dispositif de contrôle d'un véhicule, un conteneur 4 accueille d'une part des composants applicatifs tels que les composants 5 et 6 (respectivement un composant de mesure de vitesse et un composant de calcul de temps de trajet, pour cet exemple), et des services techniques 7, 8 et 9 (respectivement les traces des entrées/sorties des composants mis en oeuvre, la notification d'événements et la gestion d'asynchronisme) . En outre, le conteneur étant considéré comme un composant au même titre que tous les éléments qu'il accueille, il comporte un prolongement 10 qui est représenté comme les autres composants et qui se comporte comme eux. II en résulte que toute cette architecture est homogène et constituée de composants communiquant entre eux de la même façon, comme expliqué cidessous.
On suppose que le composant 5 désire communiquer avec le service technique 10. A cet effet, il envoie une requête d'événement au conteneur 4. Le conteneur ajoute à cette requête un morceau de code directement exécutable (code pouvant être produit uniquement par le conteneur et dénommé en anglais glue ) assurant la jonction technique entre le composant demandeur et le composant demandé, dont le contenu est fonction du besoin exprimé par le demandeur. La requête, accompagnée de ce code, est transmise au composant demandé (le service technique 10 dans le cas présent), qui se met en état de communiquer. Ensuite, le dialogue se poursuit entre les composants 5 et 10 à chaque fois via le conteneur 4 jusqu'à son achèvement. Le même processus est à chaque fois mis en oeuvre entre deux composants rattachés au conteneur 4, quelle que soit leur nature (composants en tant que tels, comme les composants 5 et 6, ou bien services techniques).
La présente invention utilise les mécanismes de réflexion offerts par la plate-forme Java pour décrire les composants sans les déformer (pratiquement pas d'intrusion dans le code des composants, les contraintes techniques sont réduites à leur plus simple expression). Ces mécanismes de réflexion permettent au programme de s'examiner et de manipuler les éléments du langage pendant son exécution, à l'aide d'une représentation objet de lui-même. L'utilisation d'éléments de programmation tels que les interfaces de marquage ("tag interfaces" en anglais) ou les annotations permet de décrire les caractéristiques de ces composants sans contrepartie (en particulier, pas de code supplémentaire dans le composant lié à l'utilisation de ces interfaces de marquage ni aux annotations).
La description des caractéristiques d'un composant se fait à l'aide des éléments suivants du modèle de composant: É Type du composant "ComponentType".
É Services du composant "ComponentServices".
É Événements du composant "ComponentEvents".
É Paramétrage du composant "ComponentParameters".
interface ou méta-donnée interface ou méta-donnée : interface ou métadonnée interface ou méta-donnée É Données du composant: interface ou métadonnée "ComponentDataServices" pour l'accès aux données, interface ou méta-donnée "ComponentDataEvents" pour les événements liés aux données.
Sur la figure 4, qui illustre un exemple de description d'un composant 11 ( component impl ) faite avant son utilisation dans une application, les quatre premières interfaces 12 (le modèle de composant) sont représentées sur une première rangée. Viennent ensuite les interfaces et les classes du composant défini pour l'application considérée: type de composant 13, services du composant 14 (services fournis) et 14A (services utilisés), événements du composant 15 (événements utilisés) et 15A (événements produits), paramètres du composant 16 (paramètres fournis) .
Sur l'exemple de la figure 5, les services et les événements liés 15 aux données sont représentés par l'utilisation de méta-données (annotations Java). Le composant 17 est décrit par: - des services techniques fournis 18 définis par des données relatives aux données du composant et auxquelles sont rattachées des annotations Java 18A, le type de composant 19, auquel est rattachée l'annotation Java 19A, des événements produits définis par des données d'événements 20, auxquelles sont rattachées des annotations Java 20A.
Selon l'invention, le conteneur assure la gestion des
composants dont il a la description.
En particulier, il gère le cycle de vie des composants, à savoir: É La création des instances des composants.
É L'activation et la désactivation des instances des composants.
É La suppression des instances des composants.
Les composants qui sont intéressés par leur cycle de vie doivent écrire du code supplémentaire pour prendre la main dans les phases qui les intéressent. Dans la figure 6, le composant 21 est intéressé par toutes les phases du cycle de vie de son cycle de vie: initialisation, suppression, panne, activation, passivation. Les transitions 22 entre ces différents états sont classées en deux catégories: des transitions 23 dites techniques (initialisation, suppression et panne) et des transitions 24 dites fonctionnelles (activation, passivation et panne).
A l'exécution de l'application, le conteneur connecte les composants de l'application en fonction de leurs besoins: É Branchement des services fournis ("provided services") dans les services utilisés ("used services") .
É Branchement des événements produits ("produced events") dans les événements consommés ("consumed events").
É Branchement des paramètres fournis ("provided parameters") dans les paramètres utilisés ("used parameters").
Le conteneur exploite la description des services techniques 15 demandés pour connecter les composants entre eux.
La figure 7 explicite un exemple de description des services techniques demandés par un composant. On y a représenté une interface 25 de modèle de composant comportant quelques exemples de services techniques pouvant être demandés par un composant 26. Le composant 26 est décrit dans l'exemple par: É Les paramètres 27 du composant (CompAParameters) sont déclarés persistants (marquage par l'interface "PersistanceCapable" ou la méta-donnée correspondante).
É Les services 28 du composant (CompAServices) sont déclarés comme étant accessible à distance (marquage par l'interface "Remotable" ou la métadonnée correspondante).
É Les événements 29 du composant (CompAEvents) sont publiés de façon asynchrone (marquage par l'interface "Asynchronous" ou la méta-donnée correspondante).
Dans tous les cas, les interfaces de marquage peuvent être remplacées par le mécanisme de méta-données proposé par le langage et la plate-forme de programmation. Dans le cas du langage Java, ces méta-données sont transcrites par des annotations. Ce qui donne le schéma de la figure 8, dans laquelle le composant 30 est décrit dans l'exemple par: -des paramètres de composant 31, auxquels est rattachée l'annotation Java 31A, - des services de composant 32, auxquels est rattachée l'annotation Java 32A, - une description de type de composant 33, à laquelle est rattachée l'annotation Java 33A, - une description d'événements produits 34, à laquelle est rattachée l'annotation Java
Claims (1)
11 REVENDICATIONS
1. Architecture à composants logiciels pour une application à plate-forme d'exécution donnant accès au niveau métaprogramme, caractérisée en ce qu'elle est une architecture à composants (2, 3) définissant explicitement toutes les caractéristiques des composants, sans pratiquement intervenir sur le code définissant ces composants, gérant les composants pendant leur exécution, et leur fournissant des services techniques, et qu'elle comporte un conteneur générique (1) accueillant d'une part des composants (2) dont la définition découle des spécifications du cahier des charges de l'application à réaliser et dépend du domaine d'utilisation de l'application, ce conteneur accueillant d'autre part des services techniques fournis (3).
2. Architecture selon la revendication 1, caractérisée en ce que les services fournis sont au moins un des services suivants: la persistance des paramètres des composants, la propagation d'événements entre composants, suivant les modes "push" ou "pull", les traces des entrées / sorties des composants, l'asynchronisme des entrées / sorties des composants, la communication distante entre les composants.
3. Procédé de mise en communication de composants logiciels pour une application à plate-forme d'exécution donnant accès au niveau métaprogramme, dans une architecture selon la revendication 1 ou 2, caractérisé en ce que le conteneur détermine automatiquement à l'exécution les caractéristiques des composants et la description des services techniques fournis par interrogation via le métaprogramme des composants et des services fournis.
4. Procédé selon la revendication 3, caractérisé en ce que les services techniques fournis sont mis à disposition des composants par un morceau de code directement exécutable généré par le conteneur.
5. Procédé selon la revendication 4, caractérisé en ce que le morceau de code assure la jonction entre deux composants quelconques.
6. Interface homme-machine, caractérisée en ce qu'elle comporte une architecture selon l'une des revendications 1 ou 2.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0507950A FR2889325B1 (fr) | 2005-07-26 | 2005-07-26 | Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme |
| EP06792572A EP1907931A1 (fr) | 2005-07-26 | 2006-07-26 | Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme |
| US11/996,926 US20080216049A1 (en) | 2005-07-26 | 2006-07-26 | Software Component-Based Architecture for Applications with Execution Platform Affording Acces to the Metaprogram Level |
| PCT/EP2006/064679 WO2007012653A1 (fr) | 2005-07-26 | 2006-07-26 | Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0507950A FR2889325B1 (fr) | 2005-07-26 | 2005-07-26 | Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2889325A1 true FR2889325A1 (fr) | 2007-02-02 |
| FR2889325B1 FR2889325B1 (fr) | 2008-06-06 |
Family
ID=36094047
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0507950A Expired - Fee Related FR2889325B1 (fr) | 2005-07-26 | 2005-07-26 | Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20080216049A1 (fr) |
| EP (1) | EP1907931A1 (fr) |
| FR (1) | FR2889325B1 (fr) |
| WO (1) | WO2007012653A1 (fr) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9164734B2 (en) * | 2011-10-10 | 2015-10-20 | Telefonaktiebolaget L M Ericsson (Publ) | Ontology-based user requirement decomposition for component selection for service provision |
| US10120796B2 (en) * | 2012-09-14 | 2018-11-06 | Sap Se | Memory allocation for long-lived objects |
| US11157259B1 (en) | 2017-12-22 | 2021-10-26 | Intuit Inc. | Semantic and standard user interface (UI) interoperability in dynamically generated cross-platform applications |
| US11501026B2 (en) * | 2020-07-13 | 2022-11-15 | Avaya Management L.P. | Method to encrypt the data at rest for data residing on Kubernetes persistent volumes |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050125809A1 (en) * | 2003-12-04 | 2005-06-09 | International Business Machines Corporation | Apparatus, methods and computer programs for monitoring processing in a data processing system or network |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6990652B1 (en) * | 1997-03-04 | 2006-01-24 | National Instruments Corporation | System and method for determining methods and properties to be invoked on objects in a graphical program |
| US6237135B1 (en) * | 1998-06-18 | 2001-05-22 | Borland Software Corporation | Development system with visual design tools for creating and maintaining Java Beans components |
| US6167563A (en) * | 1998-09-17 | 2000-12-26 | Unisys Corporation | Method and system for building components in a framework useful in developing integrated business-centric applications |
| US6742175B1 (en) * | 1998-10-13 | 2004-05-25 | Codagen Technologies Corp. | Component-based source code generator |
| US6931623B2 (en) * | 1999-08-30 | 2005-08-16 | Touchnet Information Systems, Inc. | Method of accessing data and logic on existing systems through dynamic construction of software components |
| IE20010964A1 (en) * | 2000-11-03 | 2002-05-29 | Wilde Technologies Ltd | A software development process |
| US7657868B2 (en) * | 2005-03-14 | 2010-02-02 | Research In Motion Limited | System and method for applying development patterns for component based applications |
| US7941784B2 (en) * | 2005-03-14 | 2011-05-10 | Research In Motion Limited | System and method for generating component based applications |
| US7774744B2 (en) * | 2006-04-26 | 2010-08-10 | Sap Ag | Using relatedness information for programming |
-
2005
- 2005-07-26 FR FR0507950A patent/FR2889325B1/fr not_active Expired - Fee Related
-
2006
- 2006-07-26 WO PCT/EP2006/064679 patent/WO2007012653A1/fr active Application Filing
- 2006-07-26 EP EP06792572A patent/EP1907931A1/fr not_active Withdrawn
- 2006-07-26 US US11/996,926 patent/US20080216049A1/en not_active Abandoned
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050125809A1 (en) * | 2003-12-04 | 2005-06-09 | International Business Machines Corporation | Apparatus, methods and computer programs for monitoring processing in a data processing system or network |
Non-Patent Citations (2)
| Title |
|---|
| CARSIQUE, JULIEN: "JAC - Java Aspect Components - Server d'applications Java Open-Source (LGPL) basé sur la Programmation Orientée Aspect", 14 November 2002 (2002-11-14), pages 1 - 9, XP002379066, Retrieved from the Internet <URL:http://www-igm.univ-mlv.fr/~dr/XPOSE2002/JAC/JAC%20-%20carsique.ppt> [retrieved on 20060427] * |
| PAWLAK, RENAUD ET AL: "JAC: An Aspect-Based Distributed Dynamic Framework", 5 December 2002 (2002-12-05), pages 1 - 22, XP002379067, Retrieved from the Internet <URL:http://jac.objectweb.org/docs/JAC.pdf> [retrieved on 20060425] * |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1907931A1 (fr) | 2008-04-09 |
| US20080216049A1 (en) | 2008-09-04 |
| FR2889325B1 (fr) | 2008-06-06 |
| WO2007012653A1 (fr) | 2007-02-01 |
| WO2007012653B1 (fr) | 2007-03-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101628433B1 (ko) | 애플리케이션 서버 상에서 구동되는 애플리케이션의 콤포넌트에 의한 서비스에 대한 콜을 최적화하기 위한 장치, 방법 및 머신-판독가능 저장 매체 | |
| EP1387261A1 (fr) | Logiciel de generation de code d'application informatique et langage de description de logiciel | |
| EP1768023A1 (fr) | Système de mise en oeuvre d'une application métier | |
| EP1649363B1 (fr) | Procede de gestion des composants logiciels integres dans un systeme embarque | |
| Leroy et al. | Behavioral interfaces for executable DSLs | |
| FR2889325A1 (fr) | Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme | |
| FR3021769A1 (fr) | Dispositif et procede de generation d'au moins un fichier informatique pour la realisation d'une interface graphique d'un equipement electronique, et produit programme d'ordinateur associe | |
| Indrasiri et al. | Integrating microservices | |
| EP3881515B1 (fr) | Système de supervision formelle de communications | |
| EP1262867A1 (fr) | Procédé d'implémentation d'une pluralité d'interfaces d'objets | |
| EP1494116A1 (fr) | Procédé et dispositif pour l'interfaçage graphique | |
| Mili et al. | Service-oriented re-engineering of legacy JEE applications: Issues and research directions | |
| FR2827406A1 (fr) | Methode generique de parcours d'un arbre objets pour invoquer une methode specifique sur certains objets dudit arbre | |
| Palma | Unifying service oriented technologies for the specification and detection of their antipatterns | |
| Arbab | Will the real service oriented computing please stand up? | |
| EP4206969A1 (fr) | PROCÉDÉ D'ANALYSE DE SÉCURITÉ D'UN FICHIER DE DÉPLOIEMENT D'UNE PLATEFORME &#xA;D'ORCHESTRATION D'UNE GRAPPE DE SERVEURS ; PRODUIT PROGRAMME D'ORDINATEUR ET PLATEFORME D'ORCHESTRATION ASSOCIÉS | |
| WO2020089076A1 (fr) | Executer des portions de code sur des ressources d´execution | |
| FR2787217A1 (fr) | Generation d'interface permettant d'acceder a des sites centraux | |
| Balme et al. | Ethylene: composants dynamiques pour la mise en œuvre d'IHM plastiques en informatique ambiante | |
| FR2922036A1 (fr) | Procede pour elaborer une application graphique interactive multi-entrees | |
| EP2271051A1 (fr) | Procédé d'exécution d'un service applicatif dans un environnement Web | |
| EP1697835A2 (fr) | Procede d'augmentation d'un modele de tache pour permettre la gestion de l'interaction homme-machine | |
| FR3004556A1 (fr) | ||
| FR2835948A1 (fr) | Parametrage et compilation automatique de structures utilisant des reseaux de representation standard | |
| WO2005013145A2 (fr) | Procede permettant a un utilisateur de developper des applications informatiques appliquees a des donnees qualifiees dans un systeme de gestion de donnees (sgd) |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 11 |
|
| ST | Notification of lapse |
Effective date: 20170331 |