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
Conclusion & future work
*
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
*
OutlineContext and motivation
ContributionStarting point: Case study and Framework The general
Service model The general Component model The general Agent
modelComponent Agent Service Oriented ModelMappings and
variants
Conclusion & future work
*
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 Service Model
*
Our General Service Model
*
Our General Service Model
*
Our General Service Model
*
Our General Service Model
*
Our General Service Model
*
Our General Service Model
*
Our General Service Model
*
*
Our General Component Model
*
Our General Component Model
*
Our General Component Model
*
Our General Component Model
*
Our General Component Model
*
Our General Component Model
*
Our General Component Model
*
Our General Component Model
*
Our General Component Model
*
Our General Component Model
*
Our General Component Model
*
*
Our General Agent Model
*
Our General Agent Model
*
Our General Agent Model
*
Our General Agent Model
*
Our General Agent Model
*
Our General Agent Model
*
Our General Agent Model
*
Our General Agent Model
*
Our General Agent Model
*
Our General Agent 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
*
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?
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
*
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?
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
*
Application Example in CASOM
*
Application Example in CASOM
*
Application Example in CASOM
*
Application Example in CASOM
*
Application Example in CASOM
*
Application Example in CASOM
InternalHotel Offer
*
Application Example in CASOM
*
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)
*
OutlineContext and motivation
Contribution
Conclusion & future work
*
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
*Ces point des service sont composer dune list doperations
*Ces point des service sont composer dune list doperations
*Ces point des service sont composer dune list doperations
*Ces point des service sont composer dune list doperations
*Ces point des service sont composer dune list doperations
*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
*Ces composant jouer des roles dans des interaction via leur
point de service
*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 composant jouer des roles dans des interaction via leur
point de service
*Ces composant jouer des roles dans des interaction via leur
point de service
*Ces composant jouer des roles dans des interaction via leur
point de service
*Ces composant jouer des roles dans des interaction via leur
point de service
*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
*