Changes between Initial Version and Version 1 of Ticket #120

12/22/10 10:15:08 (9 years ago)


  • Ticket #120

    • Property status changed from new to assigned
    • Property owner changed from aydan to ibaldin
  • Ticket #120 – description

    initial v1  
     1From Aydan on 12/21/2010: 
     3The portal and the rest of the system communicate - separate the web piece from ORCA server. Might as well define bean classes that would be passed through that interface.  
     5There is an xsd file in manage/standard/resource there is a types.xsd and standard.xsd. Types.xsd will have the definitions. types.xsd is the base one. add stuff to standard.xsd. Define bean there. There is an ant task one folder up called 'beans'  
     7under trunk/pom.xml there is a profile called 'ant' . this profile is a way to prepare a classpath so ant can be invoked using maven to bring necessary jars (including wsgen). This profile defines properties and will invoke by default build.xml.  
     9In manager/standard you say 'mvn -P ant -Dtarget=beans' to regenerate beans. Unfortunately these beans are (maybe) based on axis1.  
     11Look at standard.wsdl . there is a container service that is defined somewhere in some wsdl file  
     13core/shirako/resources/ look for wsdl files. There is a wsdl for the container, there is wsdl for an actor (also authority/broker/sm). The ones for the container is the initial attempt to provide management api for the container.  
     15There is a big kludge - when a sm asks broker for a ticket. broker gives back a ticket that says it is from a site. if sm goes to talk to site, there were problem rampart problems with certificate validation. rampart running at the authority would not recognize the pubkey of the sm. so now sm makes a call to the site.  
     17Going back to adding api. Resource pools are slices. so you can use slices. on the site every pool is a unique slice. every reservation from that pool is placed in this slice. meaning e.g. initial tickets delegated from that slice. Every ticket in the system originates form a site . a ticket is a reservation. that initial reservation is placed in the slice that represents the resource pool. This is used in recovery.  
     19There is a lot of replication in the system. There is a lot in boot/ that should be under manage. Moving stuff around is possible. Or replicate.  
     21Move orca.boot.inventory under manage and move ndlfactory  
     23look at poolcreator line 37 - uses reflection (FYI). 
     25Move orca.boot.inventory under manage - this will make manage depend on network but that's ok.  
     27Fold manage into the core is the strategy, because some of functionality there should not be treated as an extension.  
     29Create manage2 project and core-aux projects - manage2 will be the new xmlrpc formal guy and orca-aux would be things that are taken out of manage and eventually need to go into the core (but only after manage is retired).