EP1907931A1 - 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

Info

Publication number
EP1907931A1
EP1907931A1 EP06792572A EP06792572A EP1907931A1 EP 1907931 A1 EP1907931 A1 EP 1907931A1 EP 06792572 A EP06792572 A EP 06792572A EP 06792572 A EP06792572 A EP 06792572A EP 1907931 A1 EP1907931 A1 EP 1907931A1
Authority
EP
European Patent Office
Prior art keywords
components
component
architecture
application
container
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.)
Withdrawn
Application number
EP06792572A
Other languages
German (de)
English (en)
Inventor
Philippe Fournies
Emmanuel Grivot
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Thales SA filed Critical Thales SA
Publication of EP1907931A1 publication Critical patent/EP1907931A1/fr
Withdrawn legal-status Critical Current

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

Definitions

  • the present invention relates to a software component architecture for runtime platform applications giving access to the metaprogram level, and in particular for the development and execution of human-machine interfaces (HMI or HCI in English: “Human Computer Interface”).
  • HMI human-machine interfaces
  • the developer can not focus on the added value of development that are the features for the customer. In addition, the developer must structure his application by choosing an architecture.
  • a component architecture proposes a decomposition into weakly coupled elements (components) (with the minimum possible interdependence between them). This component architecture is regular and is applicable to the entire application. These components are weakly coupled, their maintenance, their evolution and their reuse are easier.
  • components having a regular structure, they are managed generically by a component manager (a container,
  • the presentation level can be in two different forms
  • Component architectures are primarily available for thin clients (Java Server Page-JSP, Active Server Page-ASP, etc.)
  • the known component architectures only provide a subset of all the characteristics necessary for the complete definition of a component, and which constitute a component model.
  • the component model within the meaning of the present invention. must have at least the following definitions
  • - services can be used synchronously or asynchronously,
  • the subject of the present invention is a software component architecture for runtime platform applications giving access to the metaprogram level, and in particular for the development and execution of human-machine interfaces in the context of heavy clients, which is complete and transparent, and it also relates to a man-machine interface comprising such an architecture.
  • the subject of the present invention is also a method of placing software components in communication for a runtime platform application giving access to the metaprogram level, in an architecture of the aforementioned type, process producing virtually no intrusion into the component code, the technical constraints being reduced to their simplest expression.
  • the component architecture according to the invention is a component architecture explicitly defining all the characteristics of the components, without practically intervening on the code defining these components, managing the components during their execution, and providing them with technical services, and it comprises a generic container hosting on the one hand components whose definition stems from the specifications of the specifications of the application to be made and depends on the field of use of the application, this container hosting the other technical services provided.
  • the method of the invention is characterized in that the container automatically determines at runtime the characteristics of the components and the description of the technical services provided by interrogation via the meta-program of the components and services provided.
  • the technical services provided are made available components by a piece of directly executable code generated by the container.
  • the piece of code ensures the junction between any two components.
  • FIG. 1 is a simplified block diagram of a software component architecture for developing and executing man-machine interfaces for both heavy and thin clients, architecture to which the invention may apply,
  • FIG. 2 is a simplified block diagram of the component architecture according to the invention, with the container, the application components accommodated, and the technical services. provided by the container and available for all components, - Figure 3 is a block diagram explaining operating details of the architecture of Figure 2, - Figures 4 to 8 are diagrams of examples of implementations of components according to the invention
  • EJB software component architecture for the development and execution of human-machine interfaces
  • business level which can implement standards such as EJB session, CCM, COM, Sp ⁇ ng
  • presentation level which is a workstation If this post is that of heavy clients, it usually works under JavaBeans, while for customers lge rs, it can work under JSP or ASP for example
  • the software component architecture shown in FIG. 2 essentially comprises a generic container 1 hosting, on the one hand, components 2 whose definition derives from the specifications of the specifications of the application to be produced and depends on the field of use of this application.
  • the container 1 also receives services provided such as those mentioned below.
  • the container is in charge of managing the runtime life cycle of the components II activates them, deletes them, ensures the communication between them, and connects them to the technical services they need, for example depending on the quality of service required, which can be scalable
  • the hosted components are the components developed as part of a specific application. They express in an understandable way by the container the nature of the technical services they wish to benefit from.
  • the container interprets these expressions of needs and calls the desired technical services instead of these components, for their benefit, and puts them in relation with the requesting components.
  • the architecture of the invention defines the principles of development of a component-based application by specification of compatible components of a process centered on the model UML ("model driven" in English).
  • a container 4 accommodates, on the one hand, application components such as components 5 and 6 (respectively a speed measuring component). and a trip time calculation component, for this example), and technical services 7, 8 and 9 (respectively the input / output traces of the implemented components, the event notification and the asynchronism management) .
  • the container being considered as a component in the same way as all the elements it hosts, it has an extension 10 which is represented like the other components and behaves like them.
  • this whole architecture is homogeneous and consists of components communicating with each other in the same way, as explained below.
  • the component 5 wishes to communicate with the technical service 10. For this purpose, it sends an event request to container 4
  • the container adds to this request a piece of directly executable code (code that can be produced only by the container and called in English "glue") providing the technical connection between the requesting component and the requested component, whose content is a function of The request, accompanied by this code, is transmitted to the requested component (the technical service 10 in this case), which puts itself in a state of communication.
  • the dialogue continues between the components 5 and 10 at each time. The same process is each time implemented between two components attached to the container 4, whatever their nature (components as such, such as components 5 and 6, or services techniques)
  • the present invention uses the reflection mechanisms offered by the Java platform to describe the components without deforming them (practically no intrusion into the component code, the technical constraints are reduced to their simplest expression). These reflection mechanisms allow the program to examine and manipulate the elements of the language during its execution, with the help of an object representation of itself
  • the use of programming elements such as the "tag interfaces" in English) or the annotations allows to describe the characteristics of these components without compensation (in particular, no additional code in the component to the use of these marking interfaces or annotations)
  • the description of the characteristics of a component is made using the following components of the component model
  • the container manages the components of which it has the description.
  • Components that are interested in their life cycle need to write additional code to get their hands in the phases that interest them
  • Component 21 is interested in all phases of the life cycle of its initialization life cycle, suppression, failure, activation, passivation.
  • the transitions 22 between these different states are classified into two categories: so-called technical 23 transitions (initialization, deletion and failure) and 24 so-called functional transitions (activation, passivation and failure).
  • the container connects the application components according to their needs:
  • the container uses the description of the technical services requested to connect the components to each other.
  • Figure 7 illustrates an example of a description of the technical services requested by a component.
  • An interface is represented
  • component model with some examples of technical services that can be requested by a component 26.
  • the component 26 is described in the example by:
  • Parameters 27 of the component are declared persistent (marking by the interface "PersistanceCapable” or the corresponding meta-data).
  • CompAServices are declared as being accessible remotely (marking by the "Remotable” interface or the corresponding meta-data).
  • Component events 29 are published asynchronously (marking by the "Asynchronous" interface or the corresponding metadata).
  • the tagging interfaces can be replaced by the meta-data mechanism proposed by the language and the programming platform.
  • these metadata are transcribed by annotations. This gives the diagram of FIG. 8, in which the component 30 is described in the example by: component parameters 31, to which is attached the Java annotation 31A, component services 32, to which is attached the Java annotation 32A, a description of the type of component 33, to which the Java annotation 33A is attached, a description 34, to which the Java annotation is attached

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 Model-CCM) et des COTS (Component Object Model-COM, SpπngFramework, etc ) Dans le cadre d'une architecture multi-mveaux (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 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 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 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 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 œuvre 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 œuvre 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, Spπng) 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 II 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 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 œuvre, 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. Il 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é ci-dessous.
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 œuvre 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 hé à 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 interface ou méta-donnée "ComponentType"
• Services du composant interface ou méta-donnée "ComponentServices"
• Événements du composant interface ou méta-donnée "ComponentEvents"
• Paramétrage du composant interface ou méta-donnée "ComponentParameters" • Données du composant interface ou méta-donné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 1 1 (« 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 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 2OA 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 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éta-donné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

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.
EP06792572A 2005-07-26 2006-07-26 Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme Withdrawn EP1907931A1 (fr)

Applications Claiming Priority (2)

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
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

Publications (1)

Publication Number Publication Date
EP1907931A1 true EP1907931A1 (fr) 2008-04-09

Family

ID=36094047

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06792572A Withdrawn 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

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)

* Cited by examiner, † Cited by third party
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

Family Cites Families (10)

* Cited by examiner, † Cited by third party
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
WO2002037261A2 (fr) * 2000-11-03 2002-05-10 Wilde Technologies Limited Procede de mise au point de logiciel
GB2408813A (en) * 2003-12-04 2005-06-08 Ibm Monitoring a data processing system using event metadata
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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007012653A1 *

Also Published As

Publication number Publication date
FR2889325A1 (fr) 2007-02-02
FR2889325B1 (fr) 2008-06-06
WO2007012653B1 (fr) 2007-03-15
US20080216049A1 (en) 2008-09-04
WO2007012653A1 (fr) 2007-02-01

Similar Documents

Publication Publication Date Title
US8918793B2 (en) Resolving resource contentions
KR101660148B1 (ko) 애플리케이션 서버 상에서 구동되는 애플리케이션의 콤포넌트에 의한 서비스에 대한 콜을 최적화하기 위한 장치, 방법 및 머신-판독가능 저장 매체
EP1387261A1 (fr) Logiciel de generation de code d'application informatique et langage de description de logiciel
US20110022943A1 (en) Document object model (dom) application framework
EP1768023A1 (fr) Système de mise en oeuvre d'une application métier
FR2964225A1 (fr) Procede et dispositif de deploiement et d'aide au deploiement de composants formant un systeme temps reel embarque
EP1649363B1 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
EP1907931A1 (fr) Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme
EP2169569B1 (fr) Procédé et système de communication entre applications web distinctes
WO2007141446A1 (fr) Système de gestion d'un service interactif multimodal
Monfort et al. Towards adaptable SOA: model driven development, context and aspect
Gschwind Adaptation and composition techniques for component-based software engineering
EP1262867A1 (fr) Procédé d'implémentation d'une pluralité d'interfaces d'objets
Brown Reactive Applications with Akka. NET
EP3881515A1 (fr) Système de supervision formelle de communications
Mili et al. Service-oriented re-engineering of legacy JEE applications: Issues and research directions
Borde et al. Automatic Synthesis and Adaption of Gray-Box Components for Embedded Systems-Reuse vs. Optimization
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 
D'ORCHESTRATION D'UNE GRAPPE DE SERVEURS ; PRODUIT PROGRAMME D'ORDINATEUR ET PLATEFORME D'ORCHESTRATION ASSOCIÉS
Valetto et al. Combining mobile agents and process-based coordination to achieve software adaptation
EP2271051B1 (fr) Procédé d'exécution d'un service applicatif dans un environnement web
Palma Unifying service oriented technologies for the specification and detection of their antipatterns
WO2020089076A1 (fr) Executer des portions de code sur des ressources d´execution
Barbier’s 2.3 DIAGRAMME DE CLASSE (CLASS DIAGRAM)
EP0790553B1 (fr) Outil de génération et d'exécution de commandes à interface graphique

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080125

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20090803

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20130201