Framework design

The section Understanding how the mocking works gives details on the basic principles, with further detail below.

Interceptor types

Interceptors are responsible for actually doing something when the Point Cut has been applied and its applicable. Interceptors in the framework allow you to perform many different behaviours:

• CannedResponseInterceptor - This returns the same IData every time its invoked. Its useful to have where you want a mock with fixed behaviour or to insert data before a service is called
• ExceptionInterceptor - This raises an exception in the same way as if a service had thrown an exception or raised a fault. This will interrupt the flow so taking the example above of the invoke, inserting the ExceptionInterceptor as Service D would cause the flow to be interrupted and Service C wouldn't be called.
• PipelineCaptureInterceptor - This interceptor captures the pipeline, incrementing its file version number every time its called. Its like using the WmPublic equivalent service but with the benefit of not overwriting the file and no change to the code. Would normally be used at a before or after Intercept Point.
• AssertionInterceptor - This interceptor counts the number of times it is called. Would normally be used at a before or after Intercept Point.
• BddInterceptor - This offers sophisticated BDD like functionality based on the other interceptors. Details of its syntax is on Creating mocks from a RESTful call

All of these interceptors implement org.wmaop.chainprocessor.InterceptorChainProcessor

Fundemental to all of the behaviour is the AOPChainProcessor. Its this class which you configure in the invokemanager.cnf file. Its responsible for providing all the the Advice processing and calling of the interceptors when the condition for the PointCut is matched. To change the behaviour of what happens register and unregisterInterceptors with it and make sure that it is enabled or disabled to switch the functionality on or off. When disabled it has minimal overhead.

Interaction with the AOPChainProcessor is either by its getInstance() static method or by using the services in the pkg-wm-aop package

Cost of Intercepting

When the AOPChainProcessor is disabled there is negligible overhead. Cost of execution comes from:

• Applying wild cards to ServicePipelinePointcut - If matching a service based on a JEXL expression this will be more expensive than a string equals when matching against a fixed service name. This will have the most impact on every service call
• Using JEXL pipeline expressions for Pointcut matches - When applying an additional pipeline condition to the Pointcut this is an additional overhead but is only executed after the service name match succeeds so is therefore minimal overhead when testing service names and small when the service name matches.
• Executing an Interceptor - What's performed in an interceptor will govern the cost of calling it. Generally this is usually on par with what its replacing or the cost of calling is acceptable because of the frequency of which its called. Generally, if targeting specific services, then the cost of the framework is negligible. Its only when trying to apply functionality across all services does any form of cost calculation come in to play. Within a test environment, any costs involved wont be noticed.