Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Axis2'ers:

      I've been thinking recently about a couple of things with respect to
      Axis2. First of all, the idea that we might want to support some
      concept of "service groups" - a bunch of individual services which are
      related somehow (via state, implemented with the same code, etc).
      Second of all, I'm thinking of building a JBI implementation on top of
      Axis2, and JBI's notion of "components" are deployable units which can
      each provide multiple services.

      What about changing our model slightly to enable "components" to
      implement more than one Web Service? This would entail, I believe:

      • Change axis/services to axis/components (just for clarity)
      • Add a "ComponentContext" level to the context stack between
        ServiceContext and ConfigurationContext
      • Components would be "engage()"d just like services (although looking
        at the code I don't see this for services yet... need to dig around
        more)
      • component.xml (replacement for service.xml) would contain 1..N
        <service> elements each of which looks like the current service.xml, so
        the minimal one-service file would be
        <component><service>...</service></component>. We could allow
        optimizing this to just <service> at the top level too!

      Thoughts?

      Thanks,
      --Glen

        Activity

        Hide
        Eran Chinthaka added a comment -

        Refer http://marc.theaimsgroup.com/?t=112652502100003&r=1&w=2 before reading this.

        We have a property in the message context which will be used to identify the service group context instance. This can be done using a reference parameter or if addressing is not available, using the session in http case.
        mc.setServiceGroupContextID(id)

        The EPR will be like this in http case : http://hostName:port/axis2/services/<ServiceGroupName>:<ServiceName>

        We do dispatching using any means of dispatching mechanisms available to identify the ServiceGroupDescription, ServiceDesciption and OperationDesciption.
        Then we do a dispatch checking.
        Then we do Instance Dispatching as follows.

        axisConfig.fillContextRefences(mc);

        fillContextRefences(mc)

        { 1. look up opCtxt using mc.addressingHeaders.relatesTo[0] 2. if (opCtxt != null) GOTO 9. 3. if null, create new opCtxt 4. look up SGC using mc.getServiceGroupContextID() as the key 5. if null create new sgc 6. look up service ctxt as service name as the key 7. if null create new 8. set opCtxt.setServiceCtxt(sc) 9. return }
        Show
        Eran Chinthaka added a comment - Refer http://marc.theaimsgroup.com/?t=112652502100003&r=1&w=2 before reading this. We have a property in the message context which will be used to identify the service group context instance. This can be done using a reference parameter or if addressing is not available, using the session in http case. mc.setServiceGroupContextID(id) The EPR will be like this in http case : http://hostName:port/axis2/services/ <ServiceGroupName>:<ServiceName> We do dispatching using any means of dispatching mechanisms available to identify the ServiceGroupDescription, ServiceDesciption and OperationDesciption. Then we do a dispatch checking. Then we do Instance Dispatching as follows. axisConfig.fillContextRefences(mc); fillContextRefences(mc) { 1. look up opCtxt using mc.addressingHeaders.relatesTo[0] 2. if (opCtxt != null) GOTO 9. 3. if null, create new opCtxt 4. look up SGC using mc.getServiceGroupContextID() as the key 5. if null create new sgc 6. look up service ctxt as service name as the key 7. if null create new 8. set opCtxt.setServiceCtxt(sc) 9. return }
        Hide
        Deepal Jayasinghe added a comment -

        According the last chat (31st August 2005) following implementation will look like below;

        There will be new configuration descriptor called componet.xml , and which can have multiple service elements.
        For each service element available in component.xml there would be ServiceDescription in Axis2, and after deployment happened axis2 does not care form where service came
        (from service.xml or component.xml).
        If a component.xml have four service elements then there would be four services in Axis2.

        There would be new context called ComponentContext , and it will be director child of ConfigurationContext and latter ServiceContext will be a child of that too.

        In addition to that there will be static descriptions and which is called "ServiceGroupDescription" and it will be a direct child of AxisConfiguration and later ServiceDescription will be a child of that too.

        My idea is we do not need to introduce new archive file format for the components, and the internal format should be same as service archive.

        Show
        Deepal Jayasinghe added a comment - According the last chat (31st August 2005) following implementation will look like below; There will be new configuration descriptor called componet.xml , and which can have multiple service elements. For each service element available in component.xml there would be ServiceDescription in Axis2, and after deployment happened axis2 does not care form where service came (from service.xml or component.xml). If a component.xml have four service elements then there would be four services in Axis2. There would be new context called ComponentContext , and it will be director child of ConfigurationContext and latter ServiceContext will be a child of that too. In addition to that there will be static descriptions and which is called "ServiceGroupDescription" and it will be a direct child of AxisConfiguration and later ServiceDescription will be a child of that too. My idea is we do not need to introduce new archive file format for the components, and the internal format should be same as service archive.
        Hide
        Davanum Srinivas added a comment -

        Let's start with allowing multiple services in a single jar...is that possible to do?

        – dims

        Show
        Davanum Srinivas added a comment - Let's start with allowing multiple services in a single jar...is that possible to do? – dims
        Hide
        Srinath Perera added a comment -

        We are not doing it in the 1.0 right? bring down the priority

        Show
        Srinath Perera added a comment - We are not doing it in the 1.0 right? bring down the priority

          People

          • Assignee:
            Deepal Jayasinghe
            Reporter:
            Davanum Srinivas
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development