Building two separate Symfony projects seems like a benefit rather than a cost here. You can deploy them to the same box if you want. Much of the code could be in a shared bundle of course.
On Mon, Oct 11, 2010 at 10:38 AM, Benoît <[email protected]> wrote: > 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 > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- 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
