Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Controller_Dispatcher_Soap Component Proposal

Proposed Component Name Zend_Controller_Dispatcher_Soap
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Controller_Dispatcher_Soap
Proposers Benjamin Eberlei
Zend Liaison TBD
Revision 1.0 - 24 September 2008: Initial Draft. (wiki revision: 6)

Table of Contents

1. Overview

Zend_Controller_Dispatcher_Soap extends the standard dispatcher and overwrites its dispatch() functionality to make use of a Zend_Soap_Server for handling. It offers "routing" for modules and controllers.

2. References

  • Zend_Controller_Dispatcher_Standard
  • Zend_Soap_Server

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will offer a dispatcher for an application that is completly Soap based.
  • This component will extend Zend_Controller_Dispatcher_Standard
  • This component proposes refactoring Zend_Controller_Action
  • This component allows using a Controller as additional layer between Model and Client.

4. Dependencies on Other Framework Components

  • Zend_Controller
  • Zend_Soap_Server

5. Theory of Operation

Large applications are often deployed on different servers and linked via database replication. One or many masters collect data that is replicated to the slaves. The application uses data from the slaves to display that is not critical to be up to date/or has to be calculated in complicated batch scripts via cronjob.

In this scenario moving data hence and forth between servers is a common task. Currently the Zend Framework MVC offers a out of the box way to build a web-application that serves html pages through its Front Controller. The other side, an application server that just relays and serves information via webservice has to be implemented by hand on top.

This proposed dispatcher offers to implement an application that completly servers data via SOAP (Or XML-RPC, Json, Rest). Each request is split into module and controller parts and leads to a different controller class to expose its functionality via Soap Server. Each controller therefore acts as a facade (see facade pattern) for the access to the models and can aggregate several logical steps into one. Using a controller layer between your models and your webservice clients offers to seperate concerns. Additionaly making single calls to webservices is expensive from a response time perspective. Aggregating similiar functionality into a facade (as which the controller acts) can offer performance gains.

By default the Soap Server acts in non-wsdl mode, which makes setting up an application with this dispatcher very easy but restricts its usage to a very small subset of SoapClients (probably just the PHP one). Additionally the Dispatcher can be set to autodiscover wsdl mode (Using Zend_Soap_AutoDiscover and checking for an "action" == "wsdl" so http://example.com/mod/controller would allow for autodiscovering the wsdl at http://example.com/mod/controller/wsdl) or explicit WSDL paths for each module/controller data pairs can be set.

Using the Controller architecture allows for several nice features in SOAP applications:

  • You only have a single point of entry to your soap application, making it easier to secure this single access point.
  • SoapClient classes can easily send HTTP Authentication Username and Password that could be integrated into a centralized authentication for your webservices using Controller Plugins and ACL, AUth and the HTTP Authentication Adapter.
  • Server side caching of specific module/controller/function calls.
  • Allow using DOMDocument/SimpleXML to filter response or requests at a single point for all your soap related traffic.

This proposal should also be as general as possible, implementing an abstract Zend_Controller_Dispatcher_WebService and at least a SOAP and a XML-RPC implementation.

For this proposal to be useful, Zend_Controller_Action has to be refactored:

  • WebServices expose their functionaliy through Zend_Server_Interface handle() using mostly 1:1 mappings between function names on the client and server side.
  • This is con against using the current Zend_Controller_Action that uses <name>Action() as function.
  • Also dispatch() is not really needed in a webservice enviroment.
  • Zend_Controller_Action has lots of public methods that should not be exposed in a webservice.

My proposal would be, implement a new Interface: Zend_Controller_Action_Interface and move the constructor and dispatch method to it. Only this two methods,
because nothing more is needed in general, action controller only means that most of the dispatching has been done and only the last routine has to be called.

Currently only the Dispatcher constructs and calls actions, so the interface can be quite unspecific in its need. Then let Zend_Controller_Action implement
the interface. This change could allow to change the Standard Dispatcher to allow for any controller just implementing the interface to be valid.

This is not at all ground of the proposal, but it would allow to build your own implementation of the action controller which suites your personal needs most.
You could even (with some work of course) use symfony, cake or whatever other frameworks controllers in a zend framework application, with some extensions.

6. Milestones / Tasks

  • Milestone 1: Community Review
  • Milestone 2: Working prototype based on Feedback
  • Milestone 3: Recommendation Stage
  • Milestone 4: Unit tests
  • Milestone 5: Documentation

7. Class Index

  • Zend_Controller_Dispatcher_Soap
  • Zend_Controller_Action_Interface
  • Zend_Controller_Action_Abstract
  • Zend_Controller_Action_Soap

8. Use Cases

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.