View
214
Download
0
Tags:
Embed Size (px)
Citation preview
A Service Oriented Architecture and Distributed Coordination-based
Approach Update
Wade Hong
Carleton University
Sept 29, 2003
Recap
• SOA approach• generative communications via space-based
programming – views an application as a set of processes coordinated
through the flow of objects into and out of one or more Spaces
– shared, network accessible repository of objects used by distributed processes for object storage and exchange
– distributed persistent (transient) shared memory– blackboard or working memory model
Multi-Agent Architecture
• multiple interacting autonomous intelligent processes
• key behaviours– autonomy– inter-agent communication
• collective behaviour is emergent– “the whole is greater than the sum of the parts”
The Agents
Core Agents 1) Optical Network Element agent2) LightSpan agent3) Cross Connect agent4) Event agents5) Network Element agent6) Lightpath agent7) Routing agent8) Switching agent9) Lightpath Service agent
Optical Network Element Agent
• CA*net 4 Lightpath device is key element for which services are to be exposed
• physical device is not yet Jini capable• situated autonomous software agent as a Jini
surrogate
ONE Services• services
– partitioning service– cross connect service– status service
LightSpan Agent
• agent responsible for handling the advertisement of available lightspans
• upon instantiation, determines the free lightspans for all the ONEs within a Jini community– uses the status services for the respective ONEs
• policies needed to determine which and when lightspans are advertised– initially all free lightspans will be advertised– periodic monitoring of ONEs– notification of lightpath teardown Space events
LightSpan Agent
Cross Connect Agent
• performs the task of creating and deleting cross connects on member ONEs– between a port and a port, a port and an STS channel on a port, or
an STS channel on a port and an STS channel on a port
• interacts directly with the CA*net 4 Lightpath Space– template matches for create and delete cross connect objects
intended for the member ONEs
• locates the ONE cross connect service and through its proxy initiates the cross connect action
Cross Connect Agent
Cross Connect Agent
• transactionable methods– groups a number of cross connect actions as a
transaction
– two phase commit
– creating and removing an end-to-end lightpath as a single transaction is important
• ensures reliability and consistency
– capability will be evolved as the agent is developed
Network Element Agent
• interacts with active network devices such as routers or switches– typically, edge devices at the ingress and egress of the
requested lightpath
• services– ASPATH service– Re-routing service– VLAN service– Status service
Network Element Agent
Routing Agent
• performs the task of adding, modifying or deleting routes on respective NEs
• retrieves the routing request entry from the CA*net 4 Lightpath Space– locates the the re-routing service for the NE
– performs the re-routing
– may be performed as part of a transaction
Routing Agent
Switching Agent
• performs the task of creating or deleting VLANs on respective NEs
• retrieves the switch request entry from the CA*net 4 Lightpath Space– locates the the VLAN service for the NE– performs the switching– may be performed as part of a transaction
Switching Agent
Lightpath Agent
• transient agent created by the Lightpath Services agent– lightpath creation or deletion request conveyed through a Lightpath
Provisioning or Deprovisioning Request entry in the CA*net 4 Lightpath Space
• instance of a lightpath agent is created to act on behalf of each grid-based application
• interacts with the CA*net 4 Lightpath Space to locate and construct an end-to-end lightpath
• similar in behaviour to the end-to-end co-reservation agent in GARA (Globus Architecture for Reservation and Allocation)
LightPath Agent
Lightpath Agent
• searches the CA*net 4 Lightpath Space with template matching to locate lightspan objects which can be concatenated together to construct an end-to-end lightpath– matches may have varying granularity satisfying given constraints such
as bandwidth, period of availability, etc
• creates a set of cross connect objects and groups them into one atomic transaction– if the transactions succeed, the respective cross connect objects and
lightspan objects removed from the Space
Lightpath Agent
Lightpath Agent
• however, to utilize the end-to-end lightpath, traffic must be re-routed across it– creates routing or switch request entries and injects them into the
CA*net 4 Lightpath Space– two requests, one for each terminus form a transaction
• when the application completes, the resources can be released • deprovisioning entails writing a set of delete cross connect
objects into the CA*net 4 Lightpath Space and grouping as a single atomic transaction– routing or switch entries to delete the injected route or teardown the
created VLAN are injected into the CA*net 4 Lightpath Space
Event Agents
• source of events or alarms of interest– CA*net 4 Lightpath cross connect devices and
connected edge devices
• a set of agents is envisaged to interact with the status service of the ONEs and the NEs– more can be added as required
• inserts remote event entries into the CA*net 4 Lightpath Space
Event Agents
Lightpath Service Agent
• a grid service instance created by the Lightpath Grid Service factory
• recursively behaves as a factory to create a corresponding Lightpath agent
• intermediary between the external Grid Services façade and the internal Jini/Javaspace implementation
• similar to the Double Agent in Cisco’s Scalable Infrastructure (SI)– speaks protocol (grid services) and speaks Space
Lightpath Service Agent
• conveys a lightpath provisioning request by writing a Lightpath Provisioning Request entry into the CA*net 4 Lightpath Space– similarly, a Lightpath Deprovisioning Request to teardown the
lightpath
• transient service created with a specified lifetime– assume that the grid service minimum acceptable lifetime upon
creation is greater than the requested lease duration
Lightpath Grid Service
• a factory which creates instances of Lightpath Service Agents upon invocation from Grid appplications
• simple factory hosted on a J2EE or SunOne environment• assume that the grid service location is well known
Lightpath Grid Service
1) The Grid app sends a request to create a Lightpath Service Agent
2) Lightpath Service Agent is created by Lightpath Grid Service
3) Grid app communicates with the Lightpath Service Agent via returned GSR
4) Lightpath Agent instance is created by the Lightpath Service Agent
5) Lightpath Service Agent and Lightpath Agent communicate through CA*net 4 Lightpath Space
Partitioning Tool
• Graphical tool to allow operator to create initial partitioning and edit assets it owns– Java Swing application designed to interact with the
partitioning service and the status service of an ONE agent
– permits an authorized user to partition STS channels at a port
– Recursive delegation • national, regional, institutional, departmental
• useful for populating test lightspan objects into C4 Lightpath Space
Where Are We?• expected to be a bit further along• planned to have the ONE/TL1 class library, Partitioning
Tool, ONE agent, NE agent, LightPath agent, LightSpan agent, CrossConnect and Event agents completed– ONE/TL1 class library nearing completion– NE browser also being created– initial Partitioning Tool nearly finished– partially completed ONE, NE, LightPath, LightSpan,
CrossConnect and Event agents
Progress
• estimate that we are about 6 weeks behind schedule
– still plan to meet the projected completion date of end of December
– hope to be able to demo system by end of November
Some Issues
• Jini 2.0 released this summer– improved security model, new remote execution model
• implementation still with Jini 1.2.1• considering some elements of Project RIO
• replicated JavaSpaces with GigaSpaces still being considered– GigaSpaces not yet Jini 2.0
• how do we deal with discovering Spaces?
InterSpace Peering
• consider the scenario of an end-to-end lightpath across multiple national R&E networks– a requested lightpath terminates with endpoints in both
domains
– the originating Lightpath agent does not have visibility into the adjacent Lightpath Space
– assuming agreements and policies are in place, it may be feasible to advertise lightspan entries from one Space to another
InterSpace Peering
InterSpace Peering
• InterSpace Agent– intermediary between Lightpath Spaces– re-advertise lightspan objects from one Space to another– copies entries intended for the adjacent Space from the
current Space, eg cross connect objects– similar to the Betweener Agent in Cisco’s SI
• Peering Lightpath Agent– recast requests which may not be recognized due to
ownership attributes as originating from a surrogate
Global Lightpath Space
PeerSpaces
• a coordination language for p2p systems• current space metaphor for Linda-like systems is
intended typically as a centralized repository service• JXTASpaces ( Busi, Manfredini, Montesor, Zvattaro 2002)
– considers the dataspace scope of peers as the union of the contents of spaces of federated hosts
– visibility is transient characterized by dynamically changing connectivity of peers
– prototype written in Java and based on JXTA
Space2Space• KimSpace , a Jini-based product has a technology
called “Joined Space”– allows for transient sharing of data between spaces– form self organizing communities of knowledge
JXTA Peer Groups
• another possible approach is to use JXTA PeerGroups to discover spaces
Project RIO: A Dynamic ServiceArchitecture
• dynamic, distributed system• dynamic service provisioning framework
– dynamic provisioning & service instantiation
• dynamic policy mechanisms– SLA management mechanisms– Fault detection & recovery
• telemetry– monitoring & metering– network wide
Project Rio
• internal Sun Jini project developed by the Advanced Technology and Edge Computing Group
• component model with QoS capabilities layered on Jini (JSBs)
• JSBs instantiated in containers called cybernodes• management system with logging