Problem solve Get help with specific problems with your technologies, process and projects.

LAMP user concerns

In this expert response, Toufic Boubez discusses LAMP usability concerns and it's relationship with SOA.

I'm a LAMP stack developer and I'm curious about where in that mix I can most effectively plug-in SOA policy management. Also, are there any loose coupling/reusability concerns that I should be aware of with LAMP development?

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.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.