|
Ideally, policy management and enforcement should be outside the scope of any development platform. To use a crude analogy, when you deploy a VPN infrastructure (gateway and clients), you typically want it to work regardless of your actual development environment (LAMP or not). The same concept of encapsulation should apply in SOA policy management. Your policies should typically be deployed in the DMZ before the SOAP request reaches the physical service endpoint. That might be between the L and the A in LAMP, but more probably outside the operating system, in an external layer. A Policy Enforcement Point (PEP) layer, in the form of an appliance or a software deployment in the DMZ is the most appropriate solution to this problem.
In any case, you are correct in raising the issue of loose coupling and reuse. To illustrate this, suppose your service policies require some level of security such as authentication/authorization, confidentiality through encryption and/or integrity through signatures. These requirements will cause your service clients to be tightly coupled to the service. Any change in the policies will cause the clients to stop functioning. The solution to this problem is what I call a Policy Application Point (PAP). A PAP would be a client-side abstraction layer that can communicate with the PEP and apply its policies to outgoing requests, effectively buffering the clients from any policy changes.
|
