1 2 Previous Next 17 Replies Latest reply on May 17, 2013 8:52 AM by goc Go to original post
      • 15. Re: Adapter concept to fully support service versioning
        kcbabo

        Hey Christoph,

         

        I saw your pull request and reviewed the code.  It actually helped me settle on the one last thing nagging me about the adapter solution for service versioning : is this a generic concept of an application like validators and transformers, or is it a decoration on a specific service?  I actually think it's the latter.  This would mean that an adapter is not specified in switchyard.xml separate from a service.  Instead, an adapter would be added to a service definition and would augment/decorate the existing service interface definition.  For example:

         

        Original service definition:

        <sca:service name="CreditCheck">
            <sca:interface.java interface="org.switchyard.quickstarts.remoteinvoker.CreditCheck"/>
        </sca:service>
        

         

        New version with different contract:

        <sca:service name="CreditCheck">
            <sca:interface.java interface="org.switchyard.quickstarts.remoteinvoker.CreditCheck2"/>
            <adapter interface="org.switchyard.quickstarts.remoteinvoker.CreditCheck" class="org.example.MyCreditCheckAdapter"/>
        </sca:service>
        

         

        I might want to play with that model a bit more, but here are the advantages I see with this approach:

        1. Adapters are not distinct from service definitions, they are part of a service definition.
        2. Adapters can be applied to specific services and are not global.
        3. Design-time governance tooling can query to see which services are being adapted.
        4. Less info for user to specify as the adapter necessarily maps to the interface for the service. This also serves as a nice consistency constaint.

         

        What do you think?

         

        cheers,

        keith

        • 16. Re: Adapter concept to fully support service versioning
          goc

          I agree with your concerns.

          The current concept provides also redundant information and enables the user to "route" requests to a completely different service.

          Keith Babo wrote:

          New version with different contract:

          <sca:service name="CreditCheck">
              <sca:interface.java interface="org.switchyard.quickstarts.remoteinvoker.CreditCheck2"/>
              <adapter interface="org.switchyard.quickstarts.remoteinvoker.CreditCheck" class="org.example.MyCreditCheckAdapter"/>
          </sca:service>
          

          This was also my first approach. After I discussed it with Erhard Siegl, I developed the adapter as it is now.

          To be consistent with SCA, an adapter could be applied this way:

          <sca:composite name="composite" targetNamespace="urn:com.objectbay:switchyard.adapter.example:0.0.1-SNAPSHOT">

              <sca:service name="MyService" promote="MyServiceBean/MyService">

                  <sca:interface.java interface="org.switchyard.adapter.example.ServiceContractV2"/>

                  <sca:extensions>

                         <adapter.java xmlns="urn:switchyard-config:adapter:1.0" class="org.switchyard.adapter.example.adapters.ServiceContractAdapter" interface="org.switchyard.adapter.example.ServiceContractV1"/>

                  </sca:extensions>

              </sca:service>

           

              <sca:component name="MyServiceBean">

                  <sca:implementation.java class="com.example.MyServiceBean" />

                  <sca:service name="MyService">

                      <sca:interface.java interface="org.switchyard.adapter.example.ServiceContractV2"/>

                  </sca:service>

              </sca:component>

          </sca:composite>

          My question here is, how to detect if a consumer uses the new or the old service contract.

          Maybe it's only my lack of insight. When an adapter is applied directly on a specific service, then there is no way to detect which service contract was used by the consumer.

          So the adapter is only applied, if the requested operation is not available in the component's new service contract.

           

          I spent some time looking how this changes affect the implementation.

          The adapter has to be applied earlier - till now it was applied in the addressing phase. That's no longer possible.

          Probably in class _serviceOperation (method: createExchange) ... ? At that it is also required to extend ServiceInterface.

           

           

          Message was edited by: Christoph Gostner

           

          Message was edited by: Christoph Gostner

          • 17. Re: Adapter concept to fully support service versioning
            goc

            Hey,

             

            I adapted the adapter concept *g* ....

            As already mentioned, the configuration looks now like following:

             

                <sca:service name="ServiceContractV2PortType" promote="ServiceContractV2Bean/ServiceContractV2">
                  <sca:interface.wsdl interface="ServiceContractV2.wsdl#wsdl.porttype(ServiceContractV2PortType)"/>
                  <sca:extensions>
                    <adapter.java xmlns="urn:switchyard-config:adapter:1.0" class="org.switchyard.adapter.example.adapters.AnnotationBasedAdapter">
                       <sca:interface.java xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" interface="org.switchyard.adapter.example.ServiceContractV1" />
                    </adapter.java>
                  </sca:extensions>
                </sca:service>
            

            I also adjusted the demo project [1],

             

            Have a look!

             

            [1] https://github.com/TrueMoe/switchyard-adapter-example

            1 2 Previous Next