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.
Related Q&A from Toufic Boubez
In this expert response, Toufic Boubez discusses the amount of monitoring that can be done with Web services at one time and possible bind spots to ...continue reading
In this expert response, Toufic Boubez discusses the advantages of using JDBC and ADO as opposed to Web services standards such as SOAP.continue reading
In this expert response, Toufic Boubez clarifies confusion about implementing governance.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.