Hello guys ! First of all, thank you for your messages.
Let's clarify my point of view: to me it's all about extending Symfony2 framework. I don't want to have to write two different Symfony2 projects, one exposing REST API to the other. I want to be able to write one project and decide as late as possible how to deploy it. It could be great to be able to configure it as easily as the database access: single server or multitier architecture. In other words, i don't want to implement a Service Oriented Architecture. By the way, in my company (a bank) Application tier is only accessible by Presentation tier. I just want to be able to use Symfony2 in a more flexible way to comply with my company recommendation, which is to separate concerns for security reasons. Scaling is not the main purpose in my case (but can be in others). The problem in PHP world is that there is no such thing as RMI to communicate between tiers. That's why I thought about SOAP. The goal is to extend Symfony2 framework by adding internal classes which implement a way to execute controller code remotely. The benefit of SOAP over standard RPC is the WSDL acting as a contract between tiers. It will be like defining a internal Symfony2 communication protocol. After reading some Symfony2 code, it's not crystal clear for me what i have to modify to implement my proof of concept. That's why I'm asking you guys ! :) Regards, Benoît On 9 oct, 18:36, Lukas Kahwe Smith <[email protected]> wrote: > On 08.10.2010, at 19:55, leppert wrote: > > > You could do this by implementing a REST API (either in JSON, SOAP, > > etc.) to communicate between the view and action layer. > > > Implement an API controller in symfony and spec out an API, and only > > have the view communicate via API (maybe via curl?). > > we have been using 3 tier architectures with quite some success here at Liip, > especially for one of our clients local.ch. the main purpose wasnt really > about security afaik. one of the key benefits is that we can scale things > separately and that alternate frontends are much easier implemented. afaik > the team uses a REST api with XML for the payload. the frontend uses XSLT to > transform the content into whatever the end users system wants (usually > html). soap seems a bit overboard, then again it might make it easier to > expose content if you have some fancy enterprise java thingi. > > regards, > Lukas Kahwe Smith > [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
