Service-Oriented Integration of Component and Organizational MultiAgent Models

Service-Oriented Integration of Component and OrganizationalMultiAgent ModelsUniversit de Pau et des Pays de l'Adour Ecole doctorale des sciences exactes et de leurs applications ED 211Spcialit : Informatique

Laboratoire d'Informatique de l'Universit de Pau et des Pays de l'Adoursous la direction dePhilippe AniortparNour Alhouda AboudEric Cariou et Eric GouardresCo-encadre par

*

OutlineContext and motivationComponent based approaches (interests and shortages)MultiAgent Systems (interests and shortages)Service Oriented ArchitectureObjective

Contribution

Conclusion & future work

*

OutlineContext and motivation

ContributionStarting point: Framework and Case studyThe general Service model The general Component model The general Agent modelComponent Agent Service Oriented ModelMappings and variants


*

Context and motivation[Sommerville, 2004]

*

Context and motivationThese approaches are not sufficient independently[Sommerville, 2004]

*

Limitations: New approach ?

Merges their interests in a single entity Keep the originality of each approach independently of the othersReach interoperable agents and components via service in one application specificationUse new gained characteristics when needed

An approach is more preponderant than the otherAn approach views the component and agent ones in equity

Context and motivation

*

Context and motivationComponent based approachesWhat is a component?Reusable entity with well specified access points (ports) to expose or use services (interfaces)Primitive simplest type of component Composite hierarchical composition of sub components

Required interfaceProvided interfaceComponents are reusable pieces of softwareCardFrontEndTicketIssureCodeTicketMoney

*

Context and motivationComponent based approaches

Which approach can overcome this problem?

EJBCCMFractalWrightRapideUML2.0EDOCReusabilitycomposition

*

Context and motivationMultiAgent System (MAS)What is an agent?Autonomous rational entity (goal directed behaviour) Social ability to cooperate, coordinate, and negotiate with each other.What is an OMAS? Sets of agents that interact with each other in a common environment forming organizations which makeup systems of collaborative services

Environment perceptsactionsinteraction

*

Context and motivationMultiAgent System (MAS)

How to integrate agents and components?

GORMASHigh levels of interactionAutonomy & goal directed behaviourFAMLAGROMNIPassiMOISEGAIA

*

Context and motivationServiceLogical representation of a repeatable business activity that has a specified outcomeServices for the integration of component and agent approachesInteroperability between service providers and consumerAbstraction a service providers or consumer can be implemented by an agent or componentRelationships with components and agentsService & component : reusability purposes Service & agent : flexibility and dynamicity purposes

requiresprovidesService providerService consumerservice

*

ServiceComponentAgentAbstractionInteroperabilityBehavioral & Goal drivenHigh-level interactionsCompositionReusabilityGlobal characteristics

*

Objective???What?Integration of component and agent approachesWhy?To benefit from the strength points of one approach in overcoming the weakness points of the other in using the jointly in distributed systems development How?1- High level of connectivity (interoperability) depending on the concept of service and high level interactions2- A framework that defines all relation kinds between the three domains

!!!

*

Agentification ComponentificationProjection / AbstractionAbstract modelsConcrete modelsFramework: overviewComponentification : the added value of the component approach to existing agentsAgentification : the added value of the agent approach to existing componentsObjective

CASOM: Component Agent Service Oriented ModelIntegration of component and agent

*


ContributionStarting point: Case study and Framework The general Service model The general Component model The general Agent modelComponent Agent Service Oriented ModelMappings and variants


*

Case studyHoliday reservation systemHotels X

Hotel X 1Hotel X 2Hotel X 3Airline Company 1 Hotel YAirline Company 2ClientA1A2Travel agency

*

ContributionFramework: models

Agentification ComponentificationProjection / AbstractionAbstract modelsConcrete models

*

MethodologyFirst step: Models studyStudy representative models in each domain (30 models)Focus on the concepts of service and interactionResult: existing models do not respond to our needsService models: participantsComponent models: low-level interactionsAgent models: implicit service

Second step: Models definitionsDefine general models where the concepts of service and interaction are central and explicitUnify some concepts name between the three modelsUse UML class diagrams + OCL to define the general models

*

*

Our General Service Model

*


*


*


*


*


*


*


*


*

*

Our General Component Model

*


*


*


*


*


*


*


*


*


*


*

*

Our General Agent Model

*


*


*


*


*


*


*


*


*


*


*

Service, component and agent models' summaryComponent ModelAgent ModelService Model

The component model implements the service modelA component implements a serviceA connector implements a complex interaction (Protocol)

Component and service models are close

The agent model implements the service modelAn agent implements a serviceA classification of interaction implements a complex interaction (Protocol)The agent model is a bit differentLogical aggregationClassification of three categories of high levels interactionMany specific concept: Goal, capability, task Service, component and agent models using Ecore model in EMFUML to Ecore refactoring No association classesDesign rules in modeling by Ecore

*

ContributionAgentification ComponentificationProjection / AbstractionAbstract modelsConcrete modelsFramework: models

CASOM: Component Agent Service Oriented ModelIntegration of component and agent it is based on component and agent models

*

Towards CASOMWhat are the same elements in the two models or which are sufficiently close to be considered as equivalent?

*

Towards CASOM: shared conceptsComponent ModelAgent Model

*

CASOM

*

Towards CASOM: similar conceptsComponent ModelAgent Model

*

CASOM

*

Towards CASOM: similar conceptsComponent ModelAgent Model

*

CASOM

*

Towards CASOMWhat are the same elements in the three models or which are sufficiently close to be considered as equivalent?

What are the elements coming from different models that can be abstracted under a same general concept in order to express that they are interchangeable?

*

Towards CASOM: structural entity generalizationComponent ModelAgent Model

*

CASOM

*

CASOM

*

Towards CASOM : Hierarchical generalizationComponent ModelAgent Model

*

CASOM

*

CASOM

*

Towards CASOM: interaction generalizationComponent ModelAgent Model

*

CASOM

*



What are the elements of a model that are not available in the other one but can nevertheless be used by its elements?

*

Towards CASOM: sharable conceptsComponent ModelAgent Model

*

CASOM

*



What are the elements of a model that are not available in the other one but can nevertheless be used by its elements?

What are the elements that are fully specific to a domain? What are the secondary elements of a model that are not required to be kept?

*

Towards CASOM: full specific conceptsComponent ModelAgent Model

*

CASOM

*

Towards CASOM: full specific conceptsComponent ModelAgent Model

*

CASOM

*

CASOM SummaryObjective?Interoperable agents and componentsComponent: high-levels of interaction, explicit goalAgent: reusable through their service point, a part of a hierarchical entity

CASOM model implements the abstract service modelA component / agent implements a service A connector /classification of interaction implements a complex interaction (Protocol)

Implement CASOM model using Ecore model in EMF

*

Application Example in CASOM

*


*


*


*


*


*


InternalHotel Offer

*


*

ContributionAgentification ComponentificationProjection / AbstractionAbstract modelsConcrete modelsComponentification : the added value of the component approach to existing agentsAgentification : the added value of the agent approach to existing componentsFramework: mappings

*

Service ComponentPropertyTransformation

Service ComponentComponent Service

AutomaticallyOKOKLost InformationNoneThe associated Protocol to a ComponentConnectorVariantsComplex interactionConnector or ComponentConnectorNone

*

Service/Component AgentPropertyTransformation

Service/Component AgentAgent Service/Component

AutomaticallyOK except Task, Capability and GoalOKLost InformationNoneTask, Capability and GoalVariantsA Connector Communication or Coordination or NegotiationNone

*

Service/Component/Agent CASOMPropertyTransformation

CASOM Service/ Component/ AgentService/ Component/ Agent CASOM

AutomaticallyOk, based on already presented transformationsNo, there are at least two choices

Lost Information The associated Protocol to a ComponentConnector, Task, Capability and GoalNoneVariantsNoneIt depends on the used element either the same or to be transformed to new elements

*

Mappings SummaryPropertyTransformation9 transformations automatic and implemented in ATLComponent Service Service AgentComponent AgentCASOM Service/ Component / Agent (based on the previous transformations)Designer intervention is needed (not implemented)Service CASOM (at least two choices to implement a service )Component / Agent CASOM (at least two choices keeping elements or transforming them to elements from the second approach)

*


Contribution


*

ConclusionAn approach to integrate agent and component approaches through servicesServices and interactions as connectivity points between agents and componentsDefinition of a framework:Three models component, agent and service are already definedInterest: a unified view of each domain centered on service and interaction Component Agent Service Oriented Model is already definedInterest:- A unified model using interoperable agents and component- The characteristics of one approach are available for the otherTransformations between the four modelsInterest: move from an application design of one model to another

The implementation of these models in a MDE environment (EMF) using Ecore and the automatic models transformations in ATL

*

Future WorksTool development Graphical editors for the four models (GMF)Transformation engine supporting the management of designer choices

ValidationDevelopment of application specifications and transformations examples (empirical experimentation)Development of a prototype making interacting components (e.g. Fractal) and agents (e.g. Jade) via Web services

Model variants/ extensionConsider the behavioural aspects, e.g., specification of a protocol Consideration of new concepts, e.g., the environment aspect in the model of agent

Thanks for your attention..

*

Works integrating components, agents and services jointlyService and ComponentService Component Architecture [Marino et al. 2009]Use services to assembly components implemented over heterogeneous environments.Service and AgentESOA [Papazoglou et al. 2004]Extend Service Oriented architecture by adding a layer for its management by coordination, monitoring and policy enforcement agentsComponent and AgentComponentification: AgentComponent [Krutisch et al.2003]reusable agents by encapsulating them in componentsAgentification: SoSAA (ComponentAgent) [Dragone et al. 2009]deliberative ComponentAgents manage functional skills within low-level componentsComponent, Agent and ServiceActiveComponent [Braubach et al. 2011]merges autonomous agents with passive SCA components

*

Service ModelsModelConcept

Service& compositionParticipantSpeci.InteractionWSDL PortBindingSoaMLPort & Service pointRPC, contract and protocolSoaRMInterfacea behavioural Model

*

Component ModelsModelConceptLow levelHigh level

Component& compositionSpeci.ServiceInteractionWRIGHTPortimplicitConnector

EJBHome &Remote InterfacesimplicitRMIUML2.0Port +InterfaceimplicitDelegation & assembly FractalClient & ServerInterfacesimplicitDelegation Binding

*

Agent ModelsModelConcept

AgentGroupServiceRoleInteractionAGRImplicit within roleACL,Organizational structure,Interaction ProtocolOMNIImplicit within roleACLOrganizational structureContractingGormasACL,Organizational structure,Interaction ProtocolGAIAACL,Organizational structure,Interaction Protocol

*

Service / component / agent CASOMPropertyTransformationService CASOMThere are at least two choices to implement services Components or agents; composites or groups, component or agent connectors, CASOM ServiceThe rules are already presented in the previous mappings according to the element Component / Agent CASOMThere are at least two choicesKeep the element in its state (e.g. component to component)Map it to other element (e.g. component to agent)CASOM Agent / component Already presented in previous mappings

*Bonjour , Aujourdhuis je presente mon travail de these entituler integration oriente service des composant et de system mutli agent organizetionele, alors ce titre donne limprsission de considerer trois domain essentiel qui sont les services, composants et agents*Cette expose contien de parti essentiasl, la premier parti consider la contexte de ce travaille en fisaent une presentation rapide pour les trois modles sparment leur point forts et faibless. Aprs je presente nontre objective avants de

*La deuxieme partie consider nos contributions qui commence par presenterLa port de notreest notre framework avec lexample dapplication la quelle on utilise au longe de notre contribution,Puis on rose general model unifier poue les trois domain princepaux de composant, agent et service,Et puis on prsent notre le modele le quel permit lintegration entre les composant et les agent par des service et qui donne la possibilite specifier des application on utilisant ces trois concepts conjointement.Puis on presenter les transformation entre les quatre modeles et les passage par les mappingsUne presentation vite fait su la partier dimplementation sera aussi presenter avants de conclure avec la liste de nos prespectives*Je commence par un rapide prsentation pour le linge de vie de quelque de systme logiciel.Les langages de programmation ont a exister depuis le 1950 le mille neuf cent cinquant (195455Fortran cobol 1960) mais les programmation structural en utilisant des block avec des control est apparu entre 1980 qui tait une pas vers le programmation oriente Object, cette dernier a ouvrir la voie vers la programmation de system distribuer qui exige des approches plus abstrait *ces systmes distribue exige des approches plus abstrait cause de besoin lier aux complexit des system, la gestion de distribution et de l'htrognit. Ces approches plus abstrait sont comme les composants, les agents et les services.Problme connu, aucun de ces approches nest pas suffisant tout seul.Depuis dizaine danne, il y a des travaux qui sintrese dj intgrer deux approches, pour surmonter leur fabilbeless.Preist et al.,2001 COMosition de service par des agent par la negotiationKrutisch:agent component reusable agentPapazoglu, ESOA monitoring AgentGrondin MadAcar? ENGINE POURMarino SCAZhang eservice component ADLL, je vais dtailler chaque approcha pour dire ce qui est pas suffisant

Alors pour quoi encore un nouvelle travaille,Peu de travaille considre les trois domines ensemble comme lapproche qui dfinie un avtivecomponent entit qui rsulte de la marge de un agent un service component.Alors pour quoi on a besoin de nouvelle approche,Dans les travaux dj prsenter on peux bien trouver que un approche est considre plus avancer que les autre, par contre dans notre approche on regarde les trois approches dans la mme vu. Dans notre approche on veux toujours utiliser chaque approche avec sec intrts orignal et aussi on peux le regarder pres les intrt acqurir

**On commence par une prsentation rapide pour les approches baser sur les composants, un composant est un entiti rutilisable avec des point dacccer bien spcifier qui sont les port pour exposer ou utiliser des service (interface). Un composant peut tre primitiveOu composite compose de s composant internes, le modele de composent dfins comment les composant dans un system peut tre composer.*Il exist dj plusieur modeles de composant come FRACTAL, CCM, EDOC, UML2, rapide et Wright, ces modles partages les deux intrts cl des : la rutilisation et la composition,Ces modles aussi partage des problmes dinteroperabilit et de niveau bas de communication sauf quand il y en a des connecter ddier pour la communication, comme dans les ADL,Alors la question mtn quel lapproache peux nous aider surmonter ces problmes?*La premier sur notre liste, cest les approches baser sur les agent. Ces quoi un agent: cest une entit autonome rationnelle qui a des capacit social pour communicaer, coordiner et negoter avec les autres agent;Quand il y des ensembles qui interagir entre eux on a des systmes mutli agent et quand ces ensemble dfinir des organisation avec des autorit entre les agents on a des systems multi agent organisationnelle . Notre recherche sintrese ce type dSMA comme il y a pas mal de points communs entre eux et entre les services comme les organisation permit de construire des systmes des service collaborative. *Plusieur modeles de SMAO existe dj comme AGR? OMNI GORMAS? MOISE? , et aussi de metamodele utiliser dans des mthodologies comme Gaia et Passi.Ces modeles partage les intrets cls des SMA qui sont le haut niveau dinteraction et les comportement diriger par les buts. Par contre cet approche aussi souffre de la manque de rutilisation et de composition qui sont dj des intrts de lapproache de composant!!! Comme il y a ce genre de complment entre les deux demains, la question mtn comment les fair integrer

La rponse est dans la troisime approche qui est baser sur les services.Le service est unereprsentationlogiqued'une activit mtier qui aun rsultat dtermin Pourquoi se focaliser sur les services ?Pour intgrer les deux approches composant et agent grce ses proprits clsLinterobabilit entre le service fournisseur et cliente qui conduit la deuxeme point qui est labstraction les fournisure et le consumatre peut etre implementer par nimport quell approache.L on est arriver des interoprable agent et composant par les serviceIl existe dj des relation entre les composant et les service et les agent et les service.- Les approches de services sont lie les approches de composant car toutes les deux se basent sur des entits rutilisables et composables, et lun peuvent tre vues comme une extension logique de lautre- Et enfin, les services sont trs lis lapproche agent car tous les deux sont caractriss par des proprits de dynamicit et de flexibilit

*Pour rsumer voici un schma qui prsente une vue gnrale des caractristiques cls pour les composant et qui sont composition et de rutilisation dune cot et de linteret de neveu dinteraction plus avance et les comportement dirige pare les but dautre cot. Les services jouentun rleclcommetantun pivot d'interoprabilitentreles agentsetles composants.*Aprs cette rapide prsentation pour les trois domain, on prsente notre objectif qui est lintegration oriente service des approches composant et agent.Pourquoi faire ?Afin de profiter des points forts dune approche pour dpasser les points faible et les inconvnients de lautre approche pour amliorer la dveloppent de system distribuerComment faire ? il nous faut considrer deux point essentiels:Premirement: enrichir le niveau de connectivit (interoprabilit) en se focalisant sur le concept de service et les interactions.Deuximement: dfinir un framework pour dfinir tout les types de relation entre les trois domaines.

*Notre Framework est une hirarchie qui contient un modle plus abstrait qui est le modle de service et trois modles au mme niveau (composant, agent et un mlange des deux via le Component Agent Service Oriented Model (CASOM)). Le modele de service peut etre projeter vers nimport quelle modele de ces trois modeles, et ce modeles peut etre projeter vers nimporte quel modle concret comme (je profiter de citer )EJB et Fractal pour les composants, AGR et OMNI pour les agents et AgentComponent (AC) pour une combinaison agents et composants.une application conforme un modle de composant ou dagents peut tre enrichie par des transformations. On peut distinguer deux formes essentielles de transformations: lagentification qui est la valeur ajoute par des proprits d'agent des composants existants, et la componentification qui est le processus inverse. Ces transformations peuvent tre appliques directement entre les modles d'agent et de composant ou en passant par lintermdiaire du modle CASOM.

**La deuxime parti de ce exposer prsent notre contribution, Avant de prsenter notre contribution, on prsenter notre objective en utilisant un cas detude de system de reservation de vacances, ce systme contient 4 actors principaux, des client, agence de voyage, company arienne et des hotel. On peux avoirs plusieur instance de chque actor mais on a choisi dapprendre un seul instance de c seuf pour les hotl intern dans le chain de hotel. On est arriver un systme qui est specifer avec des agents et des composants , les entite les plus statique les commay arienne et les hotel la quelle reultilse leur service, et en pluse dans e chain dhotel on a une composite des hotel interne la composite gre les interaction avec ses sous hote.l le client et lagence de voyage possed un espace de reflixion, par contreIl faut preciser un poin ici que dans notre cas detude on present qque laspect structural pas les cmportmenteux*Avant de prsentera nos modeles, on defins icile methodolgy la quelle on a suivi fin darriver a dfinir ces models. la prmeier tape est letude de plusieur models representitives dans chaque demain, on a focualiser sur la forme de existence de deux concept cl de service et dinteraction.

Les modeles etudier ne reponds pas notre besoin davoir linteraction et le concept de service explictement dans les modeles etudier des agent et le concept de participan invisible dans le models de service.

Pour definir nos modeld on se foucalise sur les concept generaux sant detalier les aspect comportemental.

Dans ces modeled les concept de service et interaction sont explicit et on a utilis le UML digramme plus les contraint OCL et comme on fait lunification, on a chang les nom de plusieurs concept qui partage la mme signification *Dan notre model de service un service peut tre accder par ces points de service

*Ces point des service sont composer dune list doperations







*Mtn on passe ves les models qui implment ce modele de service et on commance par le modele de composant

*Le composant fournire ou require ces service vis ses point de service*Ces composant jouer des roles dans des interaction via leur point de service

*Une composant peu etre primitive ou composite compose des compsant interagent, comme un application contian des composant interagiant alor on la define comme un composite particuler

*Ces composant jouer des roles dans des interaction via leur point de service



*Les interaction soit basic soit par des connector et dans ce cas il y aura un protocol associer





*Ces services sont spicifer par les role fuctiondelles les quelle des agents jouent dans un group les role Interactionlle fournier our requirir ces service*Les agents realiser des taches par ces capacities qui iaide definie les role functionelle*Les agents realiser des taches par ces capacities qui iaide definie les role functionelle*Les agents joues leur reoles interactionelle dans un interaction*Les agents joues leur reoles interactionelle dans un interaction*Les agents joues leur reoles interactionelle dans un interaction*Les agents joues leur reoles interactionelle dans un interaction*Les agents joues leur reoles interactionelle dans un interaction*On a une hierarchy dinteraction comme la coordiantion come Negotiation comme et de communication*Les agents joues leur reoles interactionelle dans un interaction**Comme une petit resumer de trois models on les surproser dans un seul figure,on vois bien que le model de composant est un projection direct de modele de service, par contre le modele de agent est plus different.Ce figure nous montre la faisability de deinir un modele qui represent les trois models en enlevant les concepts avec la meme signification, cett modele est Casom; on peut trouver que le modele de composant implement le modele de service comme les concept en plus sont le composant qui implement le service et le connector qui implmemnte le complex interaction dans le modele de service. contrarion le modele dagent possed bcp de concept specific paar a port les deux autre modeles*Mtna on va presenter, le modeles casom qui va permeter integrer les composant et les agent, alors pour definir se modele on basent sur les modeles dagent et de composant on posant les question suivant**Ces concept on la prendre en till quelle*******Lagent et le compsant peut etre generalizer dans des entites structurel*Dans CASOMon veux absolement garder les deux entite comme on va avoire des agent et des composant interoberable**Groupe, composant et composite peut etre generaliser sous des entites hirarchicale*On a des choix flixible davoire dune composite des agent ou des composant et meme dans une group des agent et des composant*De cote dinteraction des interaction hirearchie, on va rendre disponible tt les point de service des entit structurel, tout les interaction dans les deux modeles

Vertes projector verfier*Par linteraction on peut avoire indifferent les interaction des agent et des composants*****Les concept specific dans chaque domaine , on va les prendre en till quelle

*Alors dans CASOM, on a bien garder tt les concept de les deux Domaine, *Les concept specific dans chaque domaine , on va les prendre en till quelle

*Alors dans CASOM, on a bien garder tt les concept de les deux Domaine, *On a attan notre objective on est arrive avoir des interoperable agent et composnt via les servicesLes characterstic dune approache sont valable pour lautre par examples les composant peut utiliser les interaction de haut nievaux dagent et les agent devien reutilisable et font parti dune composite

Comme les modele de composanet et agent le modele casom implement aussi le modele de service avec le particularite que on peux choisir quele element implement le service Notre modele casom implement le modele de service, les agent ou les composant implement les service, les classifcation dune interaction et le connector implement les interaction complex dans le modele de service*Alors voic un example dapplication conformant notre modele CASOM,

*Dan cette exemple, on une organization qui contient des groups et des composite ansi que des composant

*On en a des agent classique qui negotie ic entre eux et on aussi des composant classique qui intrager entre eux pare lappelle des methode.

*Jai repondus mon objective de proposer un modele qui permitre dintregaer des composant et dagent dans la meme specification dapplication.

*On an a aussi des agent qui se commuique avec des composanet en utilisant les interaction de ces agentOu des composant qui intrager entre eux en utilsant des interaction de haut nievaux cdagent*Jai repondus mon objective de proposer un modele qui permitre dintregaer des composant et dagent dans la meme specification dapplication.

*Les agent font parti dune composite dans cette example et il utilise les connector pour dispatcher des inormation pour les sous hotel*Jai repondus mon objective de proposer un modele qui permitre dintregaer des composant et dagent dans la meme specification dapplication.

*Aprs la dfinition de quatre modles, on va prsenter les mappings entre eux on prcise si ces mappings sont automatic, avec ou san pert dinformation et si il ya des variantes pour ces mappings*Pour les mappings entre le modeles de service et composant, cest automatic, sans pert dinformation et on peux implementer les interaction complex dans le models de service par des connector ou des composant connector,

Pour la transformation inverse, cest aussi autoamtic, et on peus pert les protocole associe dune composant connectore comme il est vu comme un composant normale et puis il ya pas de variants pou cette mapping

*Ans les transformation de service/ component models vers agent, sont automatique mais necisite lintervntion de designer pour preciser les tache les capacities et les goal pour les agent , san pert dinformation et des variant

Dan ltrandormation inverse de model dagent ver le composant , cest autpomatic avec de pert dinformation de sconcept de tach, capaciter et goal et il nya pad des variant mais quand on passe de ce modele vers le composant on aura que deux nevaus de compositon

*Autant que les mappings de casom ver dautre models sont automatic et base sur les appings precedentavec ou sans pert dinformation selon les concept utiliser dans Casom,Autant pour les tranfromation des autre models versCASOM on ne sait pas qui faire comme il y aura toujours deux choix pour les transformation un deorgine de composant et lautre dagent

*Comme un petit reusme d mapping preseter, on est arriver faire 9 transformation automatiqueLes transformation entre e service et le composant sont autoamtique, reversiable et san peert

Par contre les transformations de service, componnet vers agent sont auomatique maic avec le besoin de lintervention dune concepture pour preciser les capacites requis raliser ces tach

Les transforamtion de CASOM vers les trois autre models sont automatique et sont base sure les transformations davant Par contre les transformation dautre models vers casom nesicite le choix de designer

comme il y aura toujour au mos de choix de mapping un qui dorigne dagent etlautre de composant**Dans ce travail de recherche, on a propose un approache qui integre les deux approache de compsant et des ystem multi agent organisationnelle, pour arriver cette approche: on a focaliser sur les deux concepts dinteraction et service dans chaque domainEt on a defini notre framework ou On a proposer des modele generaux representant chaque domain ou les concept de service et interaction sont explicit et centraux. On a propose le modele CASOM qui permettre davoir des interoprable agent et composant et dans CASOM lec characterist dune approache sont vaable pour lautre

Dans notre frame work on a deffini aussi les transformation entre les quatre models qui permetre de passe dune specification dapplication confroment un approache vers un autre

Ces contribution ont t implemente dans un environement qui support lingnier direger par les modeles les models via ecore et la plus par de transformation via ATL*On a des perspectives au terme cours qui est le dveloppent dune utile permettant le choix de concepteur et dans cette utile, on utilise leditor graphique pour les quatre modles et un Motors de transformation pour les passage entre ces quatre modles .

La deuxime perspective est lie la validation de ces contribution par lapplication de plusieurs exemples de spcification dapplication et de transformationEt puis le dveloppent dun application qui montre la faisabilit davoir des agents par exemple implmenter sur Jade qui interagir avec les composants de fractal par les web service

Au long terme, on va avoir des variantes des modles proposes par exemple par la considration daspect comportemental et des extensions de ces modles par considre des nouveaux concepts comme lenvernoment dans le modele dagent**On commence pare les travaux qui considre les composant et les service ensemble fin de facilitt la dynamique composition de composant comme lapproche de service component architecture.Il ya aussi pas mal de travaux considrer les approche des agent et des service comme le travaux qui tendre lapproche orient service en ajoutant des couches de management qui contiens spcifique type dagents comme coordination, monitoring, QoScomposition and Policy enforcement agents

Les approches qui considre les agent et les composent et diviser en deux approches principaux selon Krutisch qui sont la valeur ajouter de lapproache de composant des approache baser sue les agents qui sappele la componentification comme dans lagent component approach ou les autures ont encapsule les agent dans des composants.

*On commence par le modele de service, Apres les tudes de plusieurs service modles voici un petite rsume,Le concept de service est central dans tt les modles en plus de la composition de service, le concept de participant ou service provider or consumer et aussi central dans cassement tt les modles tudier, le service sont spcifier par des port, interface ou service point qui peut tre de type requis ou fournir, les interaction la plus part est de type basic en plus de interaction par Protocol. Ces concept peux aide constrir les concepts dans notre modeles, Dans notre processus on veux avoir une modle de service abstrait, on aime pas avoir le concept qui implement les servicele concept de Participant sera ajouter au niveaux plus bas , en plus dajouter le concept de role explicitement, les autre concept cest la mme que dans les autre models

*Suivant la mme mthode, voici qq modles etudier de composant Rapide de ADL.., le concept de composant primitive et composite existe dans tt les models, les spcification de composant est varie entre des interface requis et fournis et des port, il ya aussi les interface home et remonte dans le EJB, on a unifiers cs specificaion par des point de services qui represents les ports et des service qui sont les interface les interactions sont de type basic dans le plus part de modles sauf quand on utilise de Protocol ou des connectors comme le cas de SFOA ici.On a choisi de definir notre propre modeles de composant ou on garde la plus part de concept commun et on change qq nom de concept comme linterface et port fin de unifier les nom de ces concepts entre les modles prsentant les diffrent domaines, alors les ports devient des service points et les interfaces dovient les services. on aussi choisi dafficher des interactin de type complex dans cette modle qui est le connector.

* toujour, suivant la meme methode, Voici une petit rsume des concepts essentiels dans qq model organisationnel dagent, le concept d'agent est central dan la plus part des modle, le concept de group existe dans qq modls,Le concept de service est explicit dans quque modles implicite dans dautre, le concept de role est explicit dans la plus part des modeles. Il ya plusieurs type dinteraction dans les modles tudier comme les interaction par la language ACL, ou interaction par contractingou par de type de ngociation.Il y a dautre concept qui vari entre les modeles etudier dans leur existance comme les concepts de task et cabability.On a choici de definir notre modele dagent ou tout les type dinteraction est bien detailer et le concept de service est explicite. Les interaction ne se limit pas par ce qui present ici

*

Actually all the transformations to the target of CASOM require the designer intervention to decide the chosen element to translate the source concept. However, an choice by default will be proposed which may be not responds to the designer or system requirement.The transformation from CASOM to any other target model is already presented in the previous table according to the original models of these concepts

*

Documents

Service-Oriented Integration of Component and Organizational MultiAgent Models