Upload
milton-freeman
View
212
Download
0
Tags:
Embed Size (px)
Citation preview
SWIM-SUIT SWIM-SUIT SWIM-SUIT Prototype SWIM-SUIT Prototype
preliminary architecturepreliminary architectureDario Di Crescenzo (Selex SI)
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 1
OUTLINEOUTLINE
• High Level SWIM Prototype Architecture Design
• Draft Scenarios and UML Model• Architecture Hypotheses • Technology Independence Scenarios
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 2
Global PictureGlobal Picture
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 3
SWIM / IOP Mgt
SWIM Network
SWIM / IOP Mgt
(Legacy) ATM System A
(Legacy) ATM System B
SWIM / IOP Mgt
(Legacy) ATM System C
SWIM / IOP Mgt
(Legacy) ATM System D
SWIM-SUIT Use cases
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 4
Basic patternsBasic patterns
• The general SWIM-based interaction schema between ATM Systems
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 5
sd ATM Systems
System A System B Another System
do_operation(a_param)
«Response»
Publish(some_data)
«Publication»Publish(some_data)
«Publication»
The SWIM-BOXThe SWIM-BOXAn high level viewAn high level view
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 6
To/From ATM Stakeholders
To/From DataLink Layer
The SWIM-Box high level structure in accordance with a layered approach :
The RolesThe Roles
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 7
• SWIM Prototype Co-operative patternsRole Definition
PUBLISHER -Receives from the Manager the coherent data D-Distributes the coherent data D to the other stakeholders
MANAGER -Collects the partial contribution from the Contributors to compute a coherent data D.-Provides the coherent data D to the Publisher
USER -Subscribes to the published data D or to a part thereof.-Consumes the updates of D
CONTRIBUTOR -Sets the value to a subset (a topic) of the information constituting the data D. The topic may be as large as the whole data when no consolidation and arbitration is required-Passes the new value of a topic of D to the Manager for partial contribution.
System I
System II
System IV
System III
1. publish A 2. consume A
2. consume A
3. publish B 4. consume B
6. publish C
7. consume C
SWIM Information Pool
5. get X
(Legacy) System I S1
(Legacy) System II S2
Client
Application
1. request
2. response
3. request
4. response
Basic operationsBasic operations
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 8
• We consider three “generic” operations that systems that
manage the Flight Data Plan, named Flight Object Servers
(FOS), could request to the underlying SWIM infrastructure :
create_FO
Create (locally) a Flight Object:Verify eligibilityAssign unique IDAssign ownership
update_FO Enable changes of Flight Object or part of it
handover_FO Allow to take the ownership of Flight Object
• The SWIM infrastructure tasks can be:– To expose service interface to ATM systems;– To build the service request;– To forward the service request to the proper provider;– To send back the outcomes of operations;– To manage the ownership of the Flight Object;
Hypothetical scenario - Hypothetical scenario - 1/31/3
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 9
• Services would be made available via SWIM from ATM Systems:– e.g. Flight Object server operations: create_FO,
update_FO, handover_FO
Hypothetical scenario - Hypothetical scenario - 2/32/3
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 10
HypotheticalHypothetical scenario - scenario - 3/33/3
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 11
Layers MappingLayers Mapping
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 12
• GOALS : To describe in details the business scenarios to detail component model of SWIM - Box
• Business scenarios analyzed :• FO Change Proposal (include “update” and ”publish”
operations)
OUTLINEOUTLINE
• SWIM Prototype Architecture Design• Draft Scenarios and UML Model• Architecture Hypotheses • Technology Independence Scenarios
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 13
Draft Scenarios and UML Draft Scenarios and UML ModelModel
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 14
• FO Change Proposal Scenario : High Level View
ATSU 1 ATSU 2 ATSU 3
ADES ADEP
SWIM
Segment Approved
“1”-
RB
T S
ub
mission
Pro
vision
al
“2” - RBT Segment Conflict Free“3” - RBT Approved
RBT ProvisionalNote: the numbers show the sequence of actions
ATSU 1 ATSU 2 ATSU 3
ADES ADEP
SWIM
Segment Approved
“1”-
RB
T S
ub
mission
Pro
vision
al
“2” - RBT Segment Conflict Free“3” - RBT Approved
RBT Provisional
ATSU 1 ATSU 2 ATSU 3
ADES ADEP
SWIM
Segment Approved
“1”-
RB
T S
ub
mission
Pro
vision
al
“2” - RBT Segment Conflict Free“3” - RBT Approved
RBT ProvisionalNote: the numbers show the sequence of actions
Draft Scenarios and UML Draft Scenarios and UML ModelModel
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 15
• FO Change Proposal Scenario : Interaction Diagram (Logical View)ATSU 1ATSU 1 SWIMSWIM ATSU_2ATSU_2 ATSU_3ATSU_3
1: proposeFOModify(FO_ID, FO)
2: verify(FO_ID, FO)
3: isConflictFree()
4: ACK
5: verify(FO_ID, FO)
6: isConflictFree()
7: ACK
8: ACK
9: update(FO_ID, FO)
Draft Scenarios and UML Draft Scenarios and UML ModelModel
• FO Change Proposal Scenario, possible details :1. The Flight must be created and associated to its ID (planning phase )2. ATSU 1, must know the Flight’s ID (FO_ID)3. ATSU 1,2 and 3 must have a local copy of this Flight Object4. ATSU 1,2 and 3 must be authorized to receive a local copy of this Flight Object5. ATSU 1, must be authorized to propose change on this Flight 6. ATSU 2 and 3, must provide “verify” functionality for this Flight7. ATSU 2 and 3, must be authorized to verify possible conflicts8. Only Flight Manager (owner) can modify the Flight Object
• FO Change Proposal Scenario, macro steps :1. ASTU 1,2 and 3 require subscription on Flight Data Domain ( domain partitions
)2. ATSU 2 and 3 Need to be added as a “verify” provider for the flight FO_ID3. ASTU 1 requires to verify its change proposal4. ASTU 1 requires to update the Flight Object5. Flight Manager (ATSU 1, in this case) modifies the Flight Object
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 16
Draft Scenarios and UML Draft Scenarios and UML ModelModel
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 17
Draft Scenarios and UML Draft Scenarios and UML ModelModel
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 18
ServiceProfile
EndPoint
setEndPoint()
DataProfi le
RoleDomainPartitionFilter
setRole(Role)setDomainPartition(DomainPartition)setFilter(Filter)
Registry
addEntry(Data_ID, Profile, Participant_ID)getParticipants(Data_ID, Profile) : Participant_IDsremoveEntry(Data_ID, Profile)getProfile(DATA_ID, Participant_ID)
<<Interface>>
RegistryAsTable
Entries
<<implements>>
Entry
DATA_IDProfile
Profile
DATA_IDParticipant_IDDecsription
setDataID(DATA_ID)setParticipantID(Participant_ID)setDescription(Description)
1 11 1
• The registry could store the information represented by this model
• For each flight, a system may register itself with a particular role; each System provides different services according to the role played for that flight
Role
PUBLISHER
MANAGER
USER
CONTRIBUTOR
Endpoint Examples
http://..
corbaloc
. . .
Draft Scenarios and UML Draft Scenarios and UML ModelModel
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 19
• Registration of the Service “Modify Flight Object”
• “Modify Flight Object” Service usage
OUTLINEOUTLINE
• SWIM Prototype Architecture Design• Draft Scenarios and UML Model• Architecture Hypotheses • Technology Independence Scenarios
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 20
Flight Data Domain Flight Data Domain Services ArchitectureServices Architecture
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 21
Front-End Session Bean:Implements the Web Service interface providing the Flight Data Domain Business and Administration Service
DDS: Distributes stringfied XML rapresentation of the Flight Object
DDS/JMSFDD
Facade
EJB StatelessSessionBean
SWIM PublishService
SWIM Core
SWIM-BOX Application
FDD Client
EJB Containerdistribution
DDS/JMS
SWIM-BOX Application
DDSDataReader
SWIM-BOX Application
DDSDataReader
DD
S/JM
S
Flight Object Server
Gateway create_FOupdate_FOhandover_FO
FOS
FOS
WEB
SERVICE
SWIM-BOX Application
DDSDataReader
<Departure-Airport><name>Roma Fiumicino</name><Runway> Rwy 34L <Runway>
</Departure-Airport><Destination-Airport>
<name> Paris</name><Runway> Rwy 29T <Runway>
</Destination-Airport><Aircraft> <name> Medit Atr 72-200 </name> </Aircraft>….
SOAP request
FDD Administrator
Legacy ATM System
Legacy ATM System
Scalability & Scalability & Performance: Performance:
The FDD Facade 1/2The FDD Facade 1/2
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 22
• Implemented as Stateless Session Bean in order to have:– No explicit mapping between multiple clients and stateless bean instances– The EJB container is free to serve any client’s request with any available instance
• Stateless session bean beneficial attributes – Bean pooling EJB container pools stateless bean instances and increase
performance.– Scalability Stateless session beans serve multiple clients, they tend to be more
scalable when applications have a large number of clients. Require less instantiation compared to stateful session beans.
– Performance An EJB container will never move a stateless session bean from RAM out to a secondary storage (as for a stateful session bean)
FDDFacade
createFO(FO) : FlightObjectIdupdateFO(FlightObjectID, FOClusterId, FOCluster)handoverFO(FlightObjectId)FDDOperation(...)
Scalability & Scalability & Performance:Performance:
The FDD Facade 2/2The FDD Facade 2/2
14/05/2008 23Flight Object Server
SOAP request
Legacy ATM System
Legacy ATM System FDD
Facade
SWIM Publish Service
SWIM-BOX Application
EJB Container
WEB
SERVICE
FO_BeanFO_id1
FO_BeanFO_id2
FO_BeanFO_idn
FDDFacade
SWIM Core
Session StatelessBean pool
Flight Object Entity Beans
Gateway
DB
Entity Beans are used to represent Flight Objects in order to have:• Container Managed Persistence• LifeCycle QoS • Business code
High Level View of FDD Architecture:High Level View of FDD Architecture: Publishing FO Publishing FO
15/05/2008 24
InvocationNetwork
InvocationNetwork
ClientClient
FDDFacadeSession
Bean
FDDFacadeSession
Bean
FO EntityBean
(FO_ID, FO)
FO EntityBean
(FO_ID, FO)
FO EntityBean
(FO_ID, FO)
FO EntityBean
(FO_ID, FO)
FO EntityBean
(FO_ID, FO)
FO EntityBean
(FO_ID, FO)
FO EntityBean
(FO_ID, FO)
FO EntityBean
(FO_ID, FO)
ClientClient DDS/JMSDDS/JMS
Ejb Container
DBDB
SWIMPublishService
SWIMPublishService
1 create_FO (FO) update_FO (FO_ID, FO,CLUSTER_ID)handover_FO (FO_ID)
3 following the FDD operation of the state on the EJB, the distribute operation is called (if Manager) or forwarded to the Manager of the current FO_ID
2 create/retrieve the EJB with FO_ID as Primary key
Redy/PooledRedy/Pooled
Stored (DB)Stored (DB)
FlightObjectlifecycle
createFO handoverFO
FDDFacadeSession
Bean
FDDFacadeSession
Bean
Loaded from DBwhen the Publisher is local
High Level View of FDD High Level View of FDD Architecture: Architecture: Receiving FOReceiving FO
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 25
InvocationNetwork
InvocationNetwork
FO EntityBean
(FO_ID, FO)
FO EntityBean
(FO_ID, FO)
FO EntityBean
(FO_ID, FO)
FO EntityBean
(FO_ID, FO)
DDS/JMSDDS/JMS
DBDB
DDS Listeneror
MDB
DDS Listeneror
MDB
1 on_data_available(..) onMessage(..)
2 retrieve the EJB with FO_ID as Primary key
3 invoke the ejb_data_available in order to process the FO
LegacySystem
LegacySystem
4 the request is processed by the Legacy System
Ejb Container
Some ideas for FDD Design:Some ideas for FDD Design:Facade, DiscoveryPublisher, FO Entity Facade, DiscoveryPublisher, FO Entity
BeanBean
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 26
SessionBean
Registry
addEntry(Data_ID, Profile, ParticipantID)....()
on createFO the ownership is set inside PublisherLookupService and distributed inside the FO to all SWIM-BOXes in order to align all the PublisherLookupServices. The updates on PublisherLookupService for a given FOID will be done by an handoverFO operation
SWIMCoreListener
notify()
updates the manager info
FlightObjectEntityBean
flightObjectString : StringpublisherInBox : BooleanflightObjectId : Integer
isPublisherInBox() : Booleandistribute()setFlightObject(FO : String)setFlightObjectPart(FO : String, clusterId : FOClusterId)onAvailableData(FO : String)
FDDFacade
createFO(FO) : FlightObjectIdupdateFO(FlightObjectID, FOClusterId, FOCluster)handoverFO(FlightObjectId)FDDOperation(...)
implements
manages
PublisherLookupService
amIPublisherForFO(foId : FlightObjectId)getPublisherReferenceForFO(foId : FlightObjectId) : StringupdatePublisherReferenceForFO(foId : FlightObjectId)
uses
implements
uses
uses
Some ideas for FDD Design:Some ideas for FDD Design:Looking at the Legacy SystemLooking at the Legacy System
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 27
LegacyCommand
execute()
CommandIf
execute()
when DDS Listener or MDB receives FO, it is forwarded to the right FlightObjectEntityBean
A Command is registered to EntityBean in order to process the legacy and to adapt the FDD reply into the Legacy Protocol
Service used to execute Legacy Commands
LegacyCommandExecutor
registerFDDCommand(command : Command, commandName : String)unRegisterFDDCommand(commandName : String)performCommand(commandName : String)
executes
DataWriter
write()
QueueSender
send()
Adapter for thetechnology independance
FDDFacade
createFO()updateFO()handoverFO()FDDOperation()
SWIMCorePublisher
publish(data)
uses
uses
FlightObjectEntityBean
flightObjectString : StringmanagerInBox : BooleanflightObjectId : Integer
isManagerInBox() : Booleandistribute()setFlightObjectString(FO : String)onAvailableData(FO : String)
managespublishes
MessageDrivenBean
onMessage()
SWIMCoreListener
notify()
notifies
DDSListener
on_data_available()
implements
OUTLINEOUTLINE
• SWIM Prototype Architecture Design• Draft Scenarios and UML Model• Architecture Hypotheses • Technology Independence
Scenarios
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 28
Publish/Subscribe Publish/Subscribe ProtocolProtocol
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 29
• DDS and JMS exclusive functioning:
–The SWIM-SUIT Prototype shall be started and tested running all the SWIM-
BOXES instances or with DDS or with JMS
Publish/Subscribe Publish/Subscribe ProtocolProtocol
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 30
• DDS and JMS together:
– JMS/DDS Bridge
– ESB in order to transform protocols (JMS/DDS)
Questions?Questions?
14/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 31