Topic
10 replies Latest Post - ‏2013-01-22T22:07:51Z by cltnc28269
NickLaqua
NickLaqua
17 Posts
ACCEPTED ANSWER

Pinned topic impact analysis based on service operation rather than service

‏2013-01-10T08:39:59Z |
Are there any recommendations how to model service consumer - provider relationships in such a way that traceability is provided at a service operation level ?

So far, service operations are only represented within the service model (generated via shredding WSDL documents). The SLA relationship between applications and SLD doesn't seem to allow for operation level dependencies.

The background is that we might have internal services with multiple operations which in turn use different external services from SaaS solution providers. Changes within the external service might then only impact specific operations within the internal service,which in turn might then only impact a subset of the overall service consumers.

I am not sure whether providing different service interface specifications, or by extending the GEP model to indicate relationships at an operation level

Hope this is clear.

thx Nick
Updated on 2013-01-22T22:07:51Z at 2013-01-22T22:07:51Z by cltnc28269
  • John_Colgrave
    John_Colgrave
    8 Posts
    ACCEPTED ANSWER

    Re: impact analysis based on service operation rather than service

    ‏2013-01-11T15:10:37Z  in response to NickLaqua
    You do this by relating the SLD to specific operations using the gep63_availableOperations relationship. An SLA related to that SLD represents a dependency on only those operations.
    • NickLaqua
      NickLaqua
      17 Posts
      ACCEPTED ANSWER

      Re: impact analysis based on service operation rather than service

      ‏2013-01-18T03:33:25Z  in response to John_Colgrave
      John, thanks for the valuable comment.

      This would fulfill the requirement of understanding the relationship between consumers and services down to an operation level. There is still two questions though:

      1. Is it possible to define operation-level QoS policies (i.e. consumer A calls operation 1 200 times/day and operation 2 500/day) ? If an SLD groups multiple operations and a single SLA refers to an SLD, it seems as if one can only govern the total number of service requests across the various operations. An option would be to define a single SLD per operation, but this seems to go against the concept of SLD's.

      2. How can operation-level impact analysis be done ? Let's say, an internal service (exposing multiple operations) makes use of multiple different backend services (potentially being provided by different parties). If now the SLD for one of the backend services changes, how can we determine which of the frontend consumers is affected (as not all the consumers are using all the operations of the internal service).

      Thanks

      Nick
      • John_Colgrave
        John_Colgrave
        8 Posts
        ACCEPTED ANSWER

        Re: impact analysis based on service operation rather than service

        ‏2013-01-18T13:04:08Z  in response to NickLaqua
        The answer to the first question is indeed to define an SLD for each operation.

        If you wish to differentiate each operation of the internal service as a consumer of the backend services then you will have to have a CapabilityVersion for each method of the internal service so that the frontend consumers will have SLAs with the appropriate CapabilityVersion instances for each method of the internal service that they consume.
        • NickLaqua
          NickLaqua
          17 Posts
          ACCEPTED ANSWER

          Re: impact analysis based on service operation rather than service

          ‏2013-01-21T06:55:17Z  in response to John_Colgrave
          John,

          thanks for the comments, fair enough.

          Even though I must say that I am slightly disappointed that splitting services down into multiple "fine grained" (single operation) services seems to be the only solution to the scenario I described.

          This would have the disadvantage of generating a very large service portfolio without representing cohesion aspects (e.g. common data structures, entities) appropriately.

          But then again, given the underlying meta model where operations don't really feature at the governance or asset layer, I don't see any other solution if such a case comes up.
          • NickLaqua
            NickLaqua
            17 Posts
            ACCEPTED ANSWER

            Re: impact analysis based on service operation rather than service

            ‏2013-01-22T01:07:09Z  in response to NickLaqua
            To be a little bit more formal about my concern, splitting services per operation violates the cohesion and completeness service design principles which ultimately impact maintainability and consumability.

            It also goes against decoupling and encapsulation of the service implementation as in this case, the service implementation (i.e. which backend/internal services are called by which operation) drives the service interface design.

            see here: http://www.ibm.com/developerworks/webservices/library/ws-soa-design/

            not sure what the solution is, sounds like a trade off.

            still wondering how others do that and whether I am "overengineering" here.
            • John_Colgrave
              John_Colgrave
              8 Posts
              ACCEPTED ANSWER

              Re: impact analysis based on service operation rather than service

              ‏2013-01-22T11:18:58Z  in response to NickLaqua
              I didn't say anything about the actual service interface or implementation. I described how you could capture the operation-level dependencies you want in the default WSRR model, in a way which would work with the various uses of SLAs, SLDs etc.

              If you do not need this to fit into the existing SLA/SLD structure then you can simply add a relationship between an operation of the calling service and the appropriate operation(s) of the called service. You could use unmodeled relationships or tweak the model to add the necessary relationships.
  • NickLaqua
    NickLaqua
    17 Posts
    ACCEPTED ANSWER

    Re: impact analysis based on service operation rather than service

    ‏2013-01-22T01:07:56Z  in response to NickLaqua
    still looking for best practices
  • cltnc28269
    cltnc28269
    25 Posts
    ACCEPTED ANSWER

    Re: impact analysis based on service operation rather than service

    ‏2013-01-22T01:53:09Z  in response to NickLaqua
    Just wanted to share an approach we took at my workplace. The approach may seem radical but so far working out pretty well for us. We created entirely a model of our own - bringing in only the base model objects like WSDLDocument, XSDDocument and so on. This allowed us all the freedom to represent the notion of services/configuration, we already have at our company before we rolled out WSRR. For instance, we had REST services and other off-the road services like xml documents available in in-memory cache. Though we couldn't leverage all features available on business space and wsrr admin ui, we are very happy with the alternative-approach we have taken instead of going with governance profile. I don't know if anyone agrees or see it that way, but to me, WSRR's strength is in the ability to create your own model and taking advantage of in built UIs and APIs to operate on the model.
    • John_Colgrave
      John_Colgrave
      8 Posts
      ACCEPTED ANSWER

      Re: impact analysis based on service operation rather than service

      ‏2013-01-22T11:34:45Z  in response to cltnc28269
      Other people have adopted a similar approach. The models for things like WSDL are "baked into" the WSRR product but the higher-level models can be changed or replaced as you wish, although you may lose some of the features in WSRR and other products that depend on the default models etc. or you may have to do additional configuration of the other products.

      We ship the WSRR Studio tool to make it easy to add your own models and lifecycles or change the defaults we supply as part of the Governance Enablement Profile (GEP), and it is why the UIs adapt themselves to the models etc. as much as possible and why the APIs are generic when it comes to the higher-level models.
      • cltnc28269
        cltnc28269
        25 Posts
        ACCEPTED ANSWER

        Re: impact analysis based on service operation rather than service

        ‏2013-01-22T22:07:51Z  in response to John_Colgrave
        Absolutely! Good to know others have adopted similar approach.