Bug 2933

Summary: Refactor service context handling
Product: TAO Reporter: Johnny Willemsen <jwillemsen>
Component: ORBAssignee: DOC Center Support List (internal) <tao-support>
Status: NEW ---    
Severity: enhancement CC: jai
Priority: P3    
Version: 1.6.3   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 3243    

Description Johnny Willemsen 2007-05-16 10:06:26 CDT 
in the TAO_GIOP_Message_Generator_Parser_12 we have a check whether a bidir service context is available, and if so, it is handled. This itself is not nice because bidir is in an optional library and now the core has knowledge about this. I am experimenting with compression and there also data is transmitted through the service context and a solution could be to add also processing in the code, but that also is not a nice solution. 

It would be better if we have a registry to register service context handlers given an id and an abstract interface. An optional library (bidir, compression but also others) can then register a handler for a given id, the core of TAO then just takes the service context list, searches for each entry if there is a handler registered, if so, do a call to the handler which could then handle that service context (like bidir or compression), if no handler is registered nothing is done. This way also the orb can be independent whether we have bidir or compression and also we could plugin other service context handlers. Probably also something on the sending side could be created to have a handler that creates service contexts, maybe make a difference for the first request and then for all requests.
Comment 1 Johnny Willemsen 2007-05-16 10:06:47 CDT 
added Jai, I think he would be interested in such a thing
Comment 2 Johnny Willemsen 2007-05-16 13:47:40 CDT 
mine, will have a look at this when implementing compression
Comment 3 Johnny Willemsen 2008-03-03 12:22:28 CST 
did implement a first prototype, going to cleanup that. Idea is to have a registry of service context handlers which can be registered through the orb initializers (or any tao specific initializations). at the moment the giop code encounters a service context list, it defers the handling to the service context registry which looks if there is a sv handler for a certain context, if yes, it is triggered, if not the service context is ignored. that way other libraries (like compression) can register additional service context handlers which are then called when the service context is available. the core then has no knowledge anymore of bidir giop (as it has now)
Comment 4 Johnny Willemsen 2008-03-07 07:50:41 CST 
Fri Mar  7 13:47:30 UTC 2008  Johnny Willemsen  <jwillemsen@remedy.nl>

        * tao/BiDir_GIOP/BiDir_ORBInitializer.cpp:
        * tao/BiDir_GIOP/BiDir_Service_Context_Handler.cpp:
        * tao/BiDir_GIOP/BiDir_Service_Context_Handler.h:
        * tao/BiDir_GIOP/BiDirPolicy_Validator.h:
        * tao/GIOP_Message_Generator_Parser_12.cpp:
        * tao/GIOP_Message_Generator_Parser_12.h:
        * tao/Service_Context_Handler.cpp:
        * tao/Service_Context_Handler.h:
        * tao/Service_Context_Handler_Registry.cpp:
        * tao/Service_Context_Handler_Registry.h:
        * tao/tao.mpc:
          Made the handling of service contexts pluggable. Previously
          the core of TAO did know how to handle the IOP::BI_DIR_IIOP
          service context. Introduced a new Service Context Handler
          base class from which concrete handlers are derived, these
          handlers are then registered with the service context handler
          registry for a certain context id. This way the BiDIR
          library handles the BiDIR service context. The future
          compression support can now also be implemented without
          that the core knows much about this. The next step is to
          refactor the adding of the bidir service context to a message
          in such a way that it is pluggable.
Comment 5 Johnny Willemsen 2008-03-10 06:05:05 CDT 
added blocks
Comment 6 Johnny Willemsen 2008-06-24 06:07:52 CDT 
bidir, codeset, rtcorba, all have different plugins to add service_contexts. This all seems to be just too much. We need to have a distinction between first request and other requests, and extend the service context handler registry to also support callbacks that add service_contexts
Comment 7 Johnny Willemsen 2011-11-02 13:35:43 CDT 
to pool