Traditional way of Writing PHP
Let me draw a component diagram of a typical traditional(conventional) PHP web application.
With this design you get the advantages of the client-server architecture and the MVC design pattern.
Advantages of the Traditional Approach
- You can connect to the server from anywhere that has the connectivity to the centralized server. Say you process purchase orders in your application. Sails agents, customers around the world can connect to the application from their computers and do purchase orders. (Because of the Client-Server Architecture)
- Doing Changes to the inside of the components (Model, View and Controller) are relatively easy , because of the separation of the logics. But if changes affect to inter-communication of each component then it become harder because of the low granularity. (check disadvantages)
Are their any disadvantages of this approach?
Yes. There are plenty of them. Actually it is lot more than the advantages list.
Disadvantages of the Traditional Approach
- More Server load: The only server is responsible for maintenance of all the components. And there is no straight forward way to distribute these components in a network.
- No Interoperability: Can I replace the PHP Presentation layer with a .NET, C, Java Desktop Application with this design? No. PHP components (Model, View, Controller) are communicated in PHP code level through php function calls or may be through PHP object interactions, If you want to integrate .NET/Java to replace one component, you have to change all these function calls, object passings with each components.
- Fine Grained Interfaces: Even when I want to replace some component with another PHP implementation, it is still very difficult to integrate to the running system because of the fine-grained interfaces (Lot of small operations) used in the inter-component communication.
Mostly this issue comes when integrating new business component to existing business logic within the controller logic. The below is just a figure to demonstrate what is meant by fine-grained interface.
This causes the application to be slow (more message exchange => more time on the wire =&t; lesser speed), more traffic to the server and most importantly very hard to make interfaces consistent. (There can be many additions and removals of small operations over the time). Check this to learn more about granularity. - Business Process Automation (BPA) is impossible: Your partner companies can not purchase your products through their systems. Because they are only given a browser interface, which need human interaction. You should provide some remote interface to allow their computers to talk to your systems.
For BPA, interoperability is really important. Because your partner company may run on completely different platform and use completely different languages. I already proved traditional design will not suit to situation where interoperability is need. - Lack of security: With the above approach you have to depend on the transport level security, which is handled by your OS. There can be applications (malicious codes) run top of your OS which have back doors to these information. So for business critical messages you need to have message level security (application to application security) which secure the messages by application itself .
- Lack of reliability: In any case if the connection is lost, will my messages completely lost?. Here too you depend on the transport level reliability which you don’t have much control of.
So now lets turn to our main topic.
SOA Way of Writing PHP
With SOA, you application is no longer presenting the ‘View’ component directly. Instead it provides your business operations as a Web Service. You may implement a View with PHP using this web service. This approach allows you to implement View not only in PHP but also in other languages like .NET, Java or C as web application or desktop applications.
The business logic access the Data Layer through a Data Service. Simmilarly It can use third party Data services, Web Services to extract out the Data needed in the business process.
Let’s see how it helps you to solve the problems arouse in the traditional approach.
- Less Server load: The SOA components are natively distributed. You don’t need to process the View and the Data in the same server you process the Buisness Logic.
- High Interoperability: SOA communication happens through Web Services which is a standard protocol. There are implementations for web services in many languages and for many platforms. You can replace any components with any implementation you prefer. For an example you may first write your business logic in PHP, And as the server load goes high, you can write the buisness module in native language (‘C’) and easily intergreate to the system, without being bother of changing other components.
- Coarse grained Interfaces: The latest web services standards (e.g. WSDL 2.0) enforce the use of documents for messaging rather than invoking remote procedures. This causes the system to be consistent, maintainable and more responsive.
- Business Process Automation: Web service provide a platform to machine to machine communication. With the availability of interoperability two companies who use different implementations can communicate easily
- Security: With a WS-Security implementation you can get message level security in your application. For PHP developers there were no implementation or library that can provide WS-Security sometime ago. But as WSF/PHP is launched with many implementations for WS-* stack, that gap was closed.
- Reliability: With the WS-Reliable Messaging you can make sure a reliable communication at the application layer. You can use WSF/PHP to do reliable messaging in PHP
As your business get more complicated you can divide the logic too in to several service components as you do with data and view components. This allows you to extend your application very easily. Here is a rough design of an enterprise SOA application that you may have seen in Java and .NET paradigms. And it is time to see more of these in PHP space as well.
Pingback: PHP Coding School » Blog Archive » php code [2008-09-20 21:31:15]
In purchase orders, if I could eliminate your application, I would be much better off. This is the transport level security to learn to use your application. Purchase orders act as a very good accountability tool.
Hi Jaelynn,
In a critical business scenario Purchase orders may need to be done in a secure channel, And no doubt it requires message level security as explained in the above POST.
Dimuthu
Very nice information. Thanks for this.
Really simple and helpful article to design the application architecture using SOA. Would you please provide me your mail id to concern about my application architecture design.
Thanks for this article, it’s awesome!
However I could not access the diagrams (images) and the links seem to be broken, how can I get these images? Otherwise its very helpful.
Thanks for informing that. I just fixed it.
Dimuthu