Deleted a File by Accident?
Reverting Subversion Commits
You have deleted a file or directory and commited your change by accident? Subversion lets you undo your change quite easily.
Use svn merge -c -<revision> <URL> in your working directory. If you have local changes that you want to commit later do a fresh checkout of <URL> to a temporary directory and run svn merge there. After running svn merge you must commit your working directory for the undo to become effective.
As this completely reverses your change the same procedure can be used to recover a deleted directory or to undo other unwanted changes.
For more information see the undo section in Version Control with Subversion.
From Layers to Bus
The Way from Classical Middleware Applications to SOA
The Layered Scenario
A classical layered middleware application landscape might look like this:
A few frontend applications connected to a middleware application that connects to the backend systems. Frontend application means anything an end user interacts with. This includes web applications, interactive voice response systems as well as special devices like ATMs. The middleware applications expose business services to the frontends using a unified data model and hiding the backend calls from the frontends. Additional business logic that is missing in the backend systems is also implemented in the middleware. Finally backend applications do the central data processing, implement compliance requirements and provide a single point of truth regarding the business data. While the middleware layer is often developed inhouse, the backend applications are mainly (customized) products.
Communication takes place according to the layered structure of the landscape. Frontends talk to the middleware and the middleware talks to the backends. There are no direct calls of frontends to the backends, all backend services are wrapped (and mapped) by middleware services. Backends do not consume enhanced services of the middleware, communication between backend systems is usally implemented by batch jobs.
The Bus Scenario
On the way to SOA the connectivity and mapping features of classical middleware applications are moved into an off-the-shelf Infrastructue: the Service Bus. The goal is to replace implementation by configuration. So the backend and frontend adapter layers of the old landscape are no longer needed. The Service Bus takes over and is able to communicate with the frotend and backend applications while still ensuring appropiate encapsulation by mapping to a common vocabulary.
The Service Bus itself does not add any new services like the old middleware applications did. Therefore we will need a place for these added-value services. As you can see in the above picture the place for these features is a new Custom Services box at the level of the backend systems, now referred to as Service Producers.
As the bus architecture does not by itself enforce a caller-callee relationship Custom Services can use the backends and can be used by the frontends. In addition Custom Services now can also be used by the backends as they see fit. Finally there is no longer a need to wrap backend services by self-built services as the frontends are now able to talk "directly" to the backends while still maintaining encapsulation through the use of the mapping features of the bus infrastructure.
Consequences
The most obvious consequence is that you have to remove the frontend and backend adapters from the middleware application block. Transport Adapters are now either part of the service bus itself or the service bus provides a common transports that your applications must be enabled to connect to.
Besides transport adapters you will also need a common Enterprise Vocabulary, i.e. a data model that is understood by your services. To make the services understand this vocabulary you can either add mapping to the service bus so that (legacy) applications can still use their own vocabulary or you enable the applications to provide their services using the new vocabulary natively. Depending on the applications you have in place the one or the other option is more compelling. Often you will use a mixed approach.
Finally an important concequence is the need for more explicit Governance. While the layered scenario inherently restricts allowed dependencies the bus scenario offers much more freedom. You may want to prohibit cyclic dependencies between service blocks and make sure that service level agreements can be met (i.e. higher quality services do not depend on lower quality services). Governance is also required to define responsibilites of the now mostly equal service blocks and to evolve the common enterprise vocabulary.
Profiling PHP Applications
Using the Xdebug Extension for PHP
Ever wondered where your PHP applications spend their time?
For simple PHP scripts you can easily do basic profiling by modifying your script, take the time at critical points and log the data to a file.
As applications become more complex or make use of third party frameworks like the Zend Framework this approach does no longer work well without introducing a lot of tracing code.
We wanted to gain performance insights of a newly developed application based on Zend Framework to spot areas worth receiving some fine tuning. We did not want to modify the application for that purpose so I had a look at the options available for PHP. I finally gave Xdebug a try. Xdebug is a debugger and profiler for PHP that works as an extension that you register in your php.ini:
zend_extension="/usr/local/lib/php5/modules/xdebug.so" xdebug.profiler_enable = 1
Restart Apache and access a few pages of your application. Look at the /tmp directory on your webserver and watch for cachegrind.out files. These files contain the profiling information that we are interested in. Copy the files to your workstation for further inspection.
To analyze the profiling data you can use KCachegrind that allows you to identify the performance hogs visually:
or inspect the trace as a list:
The combination of Xdebug and KCachegrind allows you to collect and analyze profiling information from your PHP applications while they are running in their real environment without changing a single line of code.
References