Payment

When using a resource, choice promotes competition, and competition reduces cost. It should always be possible to discontinue the use of a resource in favour of a competitor. Such a move, as in the physical world, will carry an associated cost-to-change.

Ad hoc resource use and dynamic deployment encourage applications that can react quickly to changing resource availability. Use of a particular resource, or a particular deployment may represent optimal performance at a certain time, but changing circumstances may indicate redeployment or a switch of resource supplier at any time.

This seems to imply that pay-as-you-go type services are to be preferred over services which are paid for using long term contracts. Jtrix needs to support payment mechanisms natively, such that payment for service may be made alongside use of the service.

The end-to-end arguments apply. Any payment mechanism we build into the base API will likely be inadequate. Payment mechanisms are a potential minefield of security, liability, banking laws, currency conversion and exchange rates, inflation, tax, and legacy systems. The base API must provide an enabling technology, allowing payment to be transferred in a standard manner, but at the same time dictate almost nothing about the mechanisms involved.