Skip to end of metadata
Go to start of metadata

Problem

An overview over which services are used by which clients, and the frequency of their usage, is needed in order to be able to do impact analysis of what the consequences are when making changes to the contract of a service.

Context

Enterprise with many services. Nobody has a total overview of which services are used by which clients.

Forces

  • The services are implemented in many different technologies (MQ, CORBA, Java RMI, web services, CICS, etc), which means that there is no EAI/ESB product that can provide a solution to the problem.

Solution

Enforce a service usage protocol that requires a client to identify itself by using a Security Token. The token should contain enough data to identify the client in a unique manner. The service will then log this data in some appropriate format, which in turn is used to generate reports regarding the usage of the service.

Resulting Context

When implemented, the enterprise will have a automatically updated overview of usage patterns of the services.

Rationale

TBD

Related patterns

Discussion

ESB solution? In the forces section we state that no EAI/ESB products support this "out of the box". This the case as far as we know, but if anybody knows about ESB's that provide this, then please tell us.

Labels:
pattern pattern Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 13, 2008

    Please note that the pattern is a solution of auditing client usage of a service (including client type). The motivation of using this as an impact-analysis of a suggested change of contract for the service is imature as we do not have any guarrantee that clients which have knowledge of the service are actually using the service in any given period of time. We should thus probably expect that we find 80-90% of the affected clients and not 100%.

    The only way to actually do some kind of 100% impact-analysis is to enforce the architectural rule of always supplying a client-stub/proxy for the service. This client will then be the only client allowed to access the service, and guarrantee both impact analysis and smart version handling.

    1. Sep 14, 2008

      The usage data should be archived so that it is possible to see the usage statistics for the service over a fairly long period of time, like a year. If a client has never called the service in a year's time then it is probably never going to use the service.

      Always using a provided service proxy is a good principle, but in many enterprises this is not enforced. Usage statistics generated by the service should be useful even though service proxies are used.

      1. Sep 14, 2008

        And if the client added your service yesterday? Or if it uses the service as a fallback?