Zend_Soap_Server Best Practices

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Zend_Soap_Server Best Practices

Steve Finkelstein
All,

Would the following be a poor way to build a Web Service using ZF?  I currently have an MVC setup, so I'm assuming that the best way to run a SOAP based server is to include it as a Controller in the following sense:

<?php

class SoapController extends Zend_Controller_Action {
       
        public function helloWorld()
        {
               
        }  
       
       
}

$server = new Zend_Soap_Server(APP_PATH . '/wsdl/foo.wsdl');
$server->setClass('SoapController');
$server->handle();          

Is this a poor way of going about it? Are all of the examples shown not conforming to the MVC design pattern and more so just a functional setup that requires the appropriate classes?

Thank you for your 2 cents.

/sf
Reply | Threaded
Open this post in threaded view
|

Re: Zend_Soap_Server Best Practices

Lars Strojny-2
Hi Steve,

Am Samstag, den 05.07.2008, 15:01 -0700 schrieb Steve Finkelstein:
> Is this a poor way of going about it? Are all of the examples shown
> not conforming to the MVC design pattern and more so just a functional
> setup that requires the appropriate classes?

I would not say, that it is poor design, it might work fine for you,
except that passing parameters might be problematic, as
Zend_Controler_Action subclass methods don't want to get parameters.
Nevertheless, I think there is a better way. What I advocate is the
following separation of concerns:

 -------- -------------- ----------- --------- ----------
|  View  |  Controller  |  Service  |  Model  |  Storage |
 -------- -------------- ----------- --------- ----------

View and controller are self-explaining. The service layer is a coarse
grained interface to the fine grained models (it might even just consist
of static methods in service classes, as the service layer should
normally not have any runtime state) and the controller only uses the
coarse grained interfaces. E.g. you would have a UserService with a
"registerUser"-method, a "loginUser" and so on. The service layer uses
fine grained models (e.g. the object "User"), that implement the
business rules like "a username must consist of regex [a-z]+" or "a user
must have a username" to realize the coarse grained interface. The
storage is easy again, it is the CRUD layer for the data.
But back to your initial question: the cool thing is, having a service
layer allows you to easily register the service layer to RPC bridges
like Zend_XmlRpc_Server or Zend_Soap_Server.

cu, Lars

signature.asc (852 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Zend_Soap_Server Best Practices

Steve Finkelstein
Hi Lars,

Thank you kindly for the reply.  I'd just like to conform with best
practices with Zend Framework when working on my SOAP-based Web
Service.  I also want to make sure that when I create this service,
that writing a REST abstraction and XmlRpc abstraction layer will be
trivial and a lot of re-use of my model will be available.

I was looking at an example posted here:
http://electrotek.wordpress.com/2008/04/19/soap-web-service-with-zend-framework

In this instance however, I'm not sure what the author's intention is
with the Writer class.  Where would it fit into the whole 'MVC'
structure?  Is it a controller?  Is it some class placed in the
document root in its own directory?

I want to make sure I properly create the service, so that future web
services will be a matter of syntax and just re-using existing logic.

Does that make sense?

Thanks,

/sf



On Sat, Jul 5, 2008 at 6:18 PM, Lars Strojny <[hidden email]> wrote:

> Hi Steve,
>
> Am Samstag, den 05.07.2008, 15:01 -0700 schrieb Steve Finkelstein:
>> Is this a poor way of going about it? Are all of the examples shown
>> not conforming to the MVC design pattern and more so just a functional
>> setup that requires the appropriate classes?
>
> I would not say, that it is poor design, it might work fine for you,
> except that passing parameters might be problematic, as
> Zend_Controler_Action subclass methods don't want to get parameters.
> Nevertheless, I think there is a better way. What I advocate is the
> following separation of concerns:
>
>  -------- -------------- ----------- --------- ----------
> |  View  |  Controller  |  Service  |  Model  |  Storage |
>  -------- -------------- ----------- --------- ----------
>
> View and controller are self-explaining. The service layer is a coarse
> grained interface to the fine grained models (it might even just consist
> of static methods in service classes, as the service layer should
> normally not have any runtime state) and the controller only uses the
> coarse grained interfaces. E.g. you would have a UserService with a
> "registerUser"-method, a "loginUser" and so on. The service layer uses
> fine grained models (e.g. the object "User"), that implement the
> business rules like "a username must consist of regex [a-z]+" or "a user
> must have a username" to realize the coarse grained interface. The
> storage is easy again, it is the CRUD layer for the data.
> But back to your initial question: the cool thing is, having a service
> layer allows you to easily register the service layer to RPC bridges
> like Zend_XmlRpc_Server or Zend_Soap_Server.
>
> cu, Lars
>
Reply | Threaded
Open this post in threaded view
|

Re: Zend_Soap_Server Best Practices

Lars Strojny-2
Hi Steve,

Am Samstag, den 05.07.2008, 21:30 -0400 schrieb Steve Finkelstein:
[...]
> Thank you kindly for the reply.  I'd just like to conform with best
> practices with Zend Framework when working on my SOAP-based Web
> Service.  I also want to make sure that when I create this service,
> that writing a REST abstraction and XmlRpc abstraction layer will be
> trivial and a lot of re-use of my model will be available.

Yes, that's an important target to not duplicate code just for the
matter of webservices and it works fine for SOAP and XML/RPC. But REST
is a bit different, as it is *not* an RPC protocol. REST typically works
like that:

Request: PUT http://host.com/rest/user/register
        username=foo
        email=[hidden email]
Response:
HTTP/1.1 201 Created
http://host.com/rest/user/foo

As you can see, REST expresses a lot of semantics over HTTP. This is
what Zend_Rest_Server sadly does not support. In my example, you would
bind the RPC protocols to the service layer, and the REST API is created
from your controllers.

> I was looking at an example posted here:
> http://electrotek.wordpress.com/2008/04/19/soap-web-service-with-zend-framework
>
> In this instance however, I'm not sure what the author's intention is
> with the Writer class.  Where would it fit into the whole 'MVC'
> structure?  Is it a controller?  Is it some class placed in the
> document root in its own directory?

It looks like sort of a model, but not a especially realistic one. In my
world, the issue is not exporting a Writer class, but exporting complex
business logic implemented in fine grained business objects like a User
object, a Profile object, a Message object and so on.

> I want to make sure I properly create the service, so that future web
> services will be a matter of syntax and just re-using existing logic.

That's why I propose using an internal service layer which you access in
your controllers. The service layer acts as a coarse grained interface
to your fine grained business objects. Let's take a look at registering
a user. With your business objects it might look like that:

$user = new User();
$user->setUsername('foo');
$user->setEmail('[hidden email]');
$user->save();

You abstract that in the service layer and you will have that:

$user = UserServive::registerUser('foo', '[hidden email]');

To make user registrations available via SOAP, you would do the
following:

$server = new Zend_Soap_Server(...);
$server->setClass('UserService');
$service->handle();

cu, Lars

signature.asc (852 bytes) Download Attachment