SOA with Zend Framework
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

SOA with Zend Framework

on

  • 5,834 views

Implementing SOA with the Zend Framework 1.x versions.

Implementing SOA with the Zend Framework 1.x versions.

Statistics

Views

Total Views
5,834
Views on SlideShare
5,817
Embed Views
17

Actions

Likes
16
Downloads
173
Comments
0

6 Embeds 17

http://www.php-talks.com 6
http://www.linkedin.com 5
http://a0.twimg.com 2
http://www.slashdocs.com 2
http://www.phptalks.de 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

SOA with Zend Framework Presentation Transcript

  • 1. SOA withZend Framework By Mike Willbanks Software Engineering Manager CaringBridge
  • 2. About Mike… • Software Engineering Manager at CaringBridge • Open Source Contributor • Organizer of MNPHP • Where you can find me:  Twitter: mwillbanks  G+: Mike Willbanks  IRC (freenode): lubs  Blog: http://blog.digitalstruct.com2
  • 3. The Back StoryDefinitionsSOA In Other WordsA Question to Consider
  • 4. Definitions • SOA – Service-Oriented Architecture  A set of principles and methodologies for designing and developing software.  A structure for delivering content through services. • Think of a service consumer attaching to your web service; it likely is not using a database. • Service  A set of related software functionalities that can be reused for different purposes.  Essentially; the encompassed business functionality divided into tasks that streamline the interface and remove the spaghetti.4
  • 5. A Question to Consider • How often have you thought about not only how your code can serve others but how it can service you, your team along side of supporting external parties?  Think core site.  Think mobile.  Think public.5
  • 6. What I mean by that… • Slight adjustments when not using a service based model has a larger scale of changes throughout your app. • Adding caching or logging can be more difficult. • Your entity was split into multiple tables but you utilized a Zend_Db_Table for the model class. It is going to be a larger change. • Business Process in the Controller; forces implementation into the additional products and if it changes has down stream expense.6
  • 7. Make it stop!7
  • 8. Zend Framework and SOAService LayerDecorating ModelsAttaching the Servers
  • 9. Service LayerOne of the most important things when building a SOA layeris going to be the underlying services; these services areenabled by the architecture of your models.
  • 10. Aspects of a Service Layer10
  • 11. A Service • Satisfies a Business function  Function broken into Tasks • Easy consumption by your application • Allows vast re-use and more generic implementations • Decoupled to represent more or less a single item • Application logic becomes more encompassed  Filtering  Validation  Transactions / Interactions between Domain Models11
  • 12. Example Service12
  • 13. Domain Models • A domain model is a representative entity of “something” that solves a domain problem. • The entity is NOT explicitly tied to your database. • The entity essentially contains getters and setters for properties and potentially some behaviors.13
  • 14. Example Domain Model14
  • 15. Data Mapper • A data mapper handles the communication between the data source and the population of an domain model.  In a ZF context this is generally fetching data from Zend_Db_Table. • Extremely flexible and easily handles if the underlying data changes.  Alternatively; when you now have separate tables that still can represent the same domain model.15
  • 16. Example Data Mapper16
  • 17. Data Store • Persistence… you need to store it somewhere! • Data may come from several places…  File System  Web Service  NoSQL DB  Relational DB • If you utilize an ORM this is also where it would live.17
  • 18. Data Store Example18
  • 19. DecorationCachingLoggingFormatting
  • 20. Decorators? • Let’s face it… decorators do a better job decorating than we do ourselves.20
  • 21. Decorators • Decorators allow you to add new behaviors to an existing object dynamically…  Remember the previous examples? We used a few interfaces and now you will see why. • General Use Cases  Performance is becoming more of a concern and you need to implement caching.  An object is coming back with unexpected data at times; so you need to be able to log what was coming through.  You need to represent an object differently such as JSON, XML, Serialized PHP, etc.21
  • 22. Implementing Caching22
  • 23. Implementing Logging23
  • 24. Changing the Format24
  • 25. Just Decoration? • Remember decoration is just a pattern; it can help you do several things but it cannot do everything! • Don’t be afraid to utilize other patterns to assist you in the build out of your models. • The ultimate goal here is to remove the constant cost of refactoring for every feature change.25
  • 26. Attaching the ServersZend_Json_ServerZend_XmlRpc_ServerZend_Soap_ServerZend_Rest_Server
  • 27. The Server Components • All of the server components act approximately the same in terms of their API. • Each of them follow the same paradigm allowing you to connect them directly to a service object.  That means… this is going to be easy! • However, the server components utilize Reflection for AutoDiscovery as well as to understand the actual call.27
  • 28. So, docblocks are always good!28
  • 29. Implementing Servers through Controllers • Why use controllers?  Because they are already there and it fits directly into how you made your controller in the first place.  You can leverage your existing code to add them in.  Providing only a new action makes this possible.  Easily discoverable just by the URI. • In our examples – we are going to leverage an API action29
  • 30. Putting in an API method with Zend_Json_Server30
  • 31. It really is just that “easy” • We just implemented a JSON RPC server, wasn’t that easy? • You now have methods that you can call through a JSON RPC client based right off of your service object. • We did skip out on something, isn’t there a discoverability component?31
  • 32. Adding Discovery32
  • 33. The Community Wants More • The API is now exposed, people are using it but you are getting requests for additional protocols  Where is the SOAP API?  How come there is no XML RPC API?  Everyone uses more REST based API’s, WTF? • Time to implement some more!  For now, we will implement this using a type variable.33
  • 34. Multiple Servers – One API.34
  • 35. So What About those Formatters? • Previously in our decoration; I showed you how to change the output by decoration. • While they can be useful sometimes; Context Switching handles much of this for you already.  So it was really just an example but may become relevant elsewhere.35
  • 36. Example Context Switch36
  • 37. VersioningA couple options to help version your services.
  • 38. Versioning Services • There are a few different ways to version services; we know things will change and we need a way to support BC. • Versioning is important and can be implemented several ways. • They are not “perfect” but can and will work.38
  • 39. Versioning by Directory • Make version directories in your models directory  Pros • Quick to implement • Individual services take on a new version  Cons • Not all services take on the same version number; more confusing to the consumer of the service. • You need to push a version parameter to your api action • You would end up implementing fallbacks based on versions not existing.39
  • 40. Versioning by Module • Make version modules  Pros • Separation of entire service into a new module • All services take on a new version. • Simply extend the previous models.  Cons • Latest service would always be contained in a globals model folder to prevent code duplication; • Many more files; not easy to simply see what is new and what is not. • Modules work for this but; only really work if your entire api is a module and the other application is not. Which removes part of our reuse.40
  • 41. Other NotesThings worth mentioning…
  • 42. Consumer Performance • Planning for consumer performance is important for instance:  Setting a reasonable timeout on the client end.  Messaging the user if it did timeout or some other issue occurred.  Utilizing some form of caching between the service and you (something like a squid proxy) to help boost the requests per second.  Implementing local caching and keeping track of things for that user.  Utilize parallelism; if you need to grab multiple things do them at one time.  Parsing is expensive; do it one and pass it around.42
  • 43. Who are you? • When implementing web services; there are a few additional things to think about  Rate Limiting • Implemented more or less in a plug-in.  Authentication • Leveraging tokens or API keys. – A token service can deal with authentication and even allow them to have sessions through the service layer.  Authorization • Extending the server components to be aware of resources. – This is harder but gives fine grained control. • Otherwise, if you allow to a service they can access the entire service.43
  • 44. Zend Framework 2 • How will this all work in ZF2?  Well; I’m not fully sure but there is an RFC! • http://framework.zend.com/wiki/display/ZFDEV2/RFC+- +Server+Classes  All I can say; is it will be better with the new EventManager • Authorization will become easier. • Plugging in will be entirely more flexible.44
  • 45. Questions?Give me feedback: http://joind.in/3784Slides will be posted at joind.in later this afternoon.