I touched on the topic of using a service-oriented architecture (SOA), Web services, and Ajax to build a client from a theoretical perspective, but I didn’t delve into the practical details of how to implement the SOA architecture. In this feast of a article, I cover how to implement an SOA architecture using Web services and Ajax. The solution also addresses the issue of how to upgrade an already existing architecture to an SOA architecture. This article covers the following topics:

• Designing Representational State Transfer (REST)–based URLs to content that is described as a set

• Creating a new SOA architecture without throwing out all of the original architecture

• Validating and testing aWeb service

• Picking apart the data

• Implementing a REST-based Web service

• HTML

• Really Simple Syndication (RSS)

• Atom Each of the formats is unique, but the content structure within the formats is the same. From a programming perspective, the solution would involve a Model-View-Controller The re-architected application has only one URL and one data format, Atom, so the code behind the URL needs to generate content just for that format. In the case of the re-architected application, the Atom format is considered aWeb service, the idea behind which is to present a universal format understood by a wide audience. And if the end device does not understand the format, then it is up to the browsing device to figure it out. Of course, asking the end device to figure out the format might sound harsh, but it isn’t really whenever you are generating HTML using the HTTP protocol, you are asking the end device to figure out how to display the data.

If HTML and HTTP are nearly universal, why not just generate well-structured HTML and let the Atom end device figure it out? The answer is that it doesn’t work quite as smoothly as that. HTML is a user interface technology that is not universally understood across all devices. An Atom end device could probably guesstimate the format structure, but you probably know the sweat and pain associated with writing HTML code that can display on all devices. With aWeb service based on the Atom format, you have a clear understanding of what the data is and represents. For a start, aWeb service says to the server, “Here’s the data figure out how to display it.” If the end device is an Atom reader, it’s easy to figure out what to do with the data, but if the end device is aWeb browser, you have a challenge. Most new browsers do understand Atom Web services, but another option is to have Ajax at hand to help and specifically the XMLHttpRequest object, which can generate a request to call the Web service. The Web service delivers the data, which is then processed by the XMLHttpRequest object, and because the vast majority of Web services are XML based, figuring out the format of the data delivered by the Web service is trivial. By delegating the work of creating a GUI away from the server, there is a clear separation between the roles the client and server play. This separation is absolutely critical, as it allows the server developers to focus on performance, scalability, robustness, and storage, while the client can focus on usability, visual aesthetics, and understandability. The designer and the programmer have two very different skill sets, and they should not interfere with each other.

Implementing the Server The example application is a blog whose architecture will be kept plain vanilla for ease of understanding. For the blog architecture, only database support is going to be required and discussed in any depth. The legacy portion of the blog example is not code; rather, it is data generated by the previous blog software. It is not beyond the realm of possibility to write a piece of software to convert the old data into a new format, but that act itself causes more problems than it solves. Let’s put the act of converting the data from one format to another into a bigger context. Imagine writing an application that serves as an incremental version of a working application. The chances of any corporation switching from one application to another with the flick of a switch is virtually zero. Thus, for a period of time, you will have two applications running and concurrently processing data. If during that period of time your data becomes inconsistent, you will have major problems reconciling the changes and you will potentially lose data this makes it not worth the effort. Returning to the blog architecture, you could implement one of two solutions. The first solution is to use the existing database; the second is to create an adapter using aWeb service. In the blog architecture, two Web applications run concurrently, and they access, process, and manipulate the same data. This does not mean that the two applications use the same physical database. With most modern databases, you have the ability to couple two database processes and synchronize the two physical databases. This has the advantage that data consistency is managed by the database. If you plan on writing synchronization software, ask yourself if you think you could do a better job than a database when it comes to managing consistency.

The modified architecture has two database processes, and the two processes are connected using the synchronization mechanism of the database. From the perspective of the user, developer, and administrator, each application uses its own database. The two database processes manage the exact same tables, views, and stored procedures. It is assumed that this new architecture will use the same tables, views, and stored procedures, but in reality this is not always the case because a new application typically involves the addition of tables, columns, and data. The solution to this issue is to use database encapsulation, which is possible with views and stored procedures. Database synchronization reduces the complexity to an absolute minimum. The reason for using database synchronization is to begin the process of separating two applications without losing data integrity.  As the new architecture stands, the wp_authors and wp_users tables are the only dependencies of the original database. Thus, when a database synchronization is defined, only the wp_authors and wp_users tables are synchronized. Any other table used by the original blog architecture is not synchronized and thus does not affect the architecture of the new application.

 The developer can go ahead and create his or her own database design without having to worry about corrupting the old database design. It goes without saying that the old database design is not modified, but this design does not stop the creation of stored procedures that could potentially corrupt the data in the original database design. To prevent or at least minimize the potential of data corruption, it is absolutely vital that the database design use constraints and validations. Most SQL databases allow the definition of constraints. Stepping back and looking at this architecture, you should notice that it relies on the capabilities of the relational database. There could be situations where a developer is not using a relational database. For those situations, I have no solution, as for the most part I have to deal with relational databases, and I am tempted to believe most readers have the same problem. Relying on the capabilities of the relational database requires that you understand the database. With the introduction of object-relational mapping (ORM) tools, the need to know SQL is reduced. For example, using ORM tools such as Hibernate does not require knowledge of views or stored procedures. ORM tools create “views” in the form of object hierarchies. Using an ORM tool allows you to implement the same architecture; however, it means that you will probably not be using stored procedures and views.

The real difference between using an ORM and the relational database stored procedure and view solution is the shifting of the coupling between the code and the persistence of the data. By contrast, the relational database layer uses views and stored procedures to interact with the data. The coder needs to know about the columns and types of the relational database and has to provide a mapping between his or her programming language and the SQL programming language. Using classical programming languages such Java and C# involves quite a bit of legwork in terms of preparing commands and retrieving data. Using a programming language such as Ruby, Python, or PHP, interacting with a relational database is trivial since the aforementioned languages do not have to declare the data types. Using an ORM, the coder washes his or her hands of the problem and puts the focus on the ORM layer.

For Java and C# programmers, an ORM removes the drudgery of interacting with a database, with the only cost being the programmers’ lack of control of the transactions and manipulations of the database although in most cases that lack of control is acceptable when weighed against the drudgery of writing the relational database code. The question is, which architecture should you use? Personally, I use whatever is easiest in the programming language I am developing in at the time. So when I am writing code in Java and C#, I tend to use ORMs, and when I’m writing Python code, I access the relational database directly. You need to ensure that the ORM layer does not dictate the design of the database, under any circumstances. The database design is determined by the database and the data being persisted, so it means you need to understand table, view, constraint, and trigger design. This could become tricky if the ORM dictates the database design, and it could result in an inefficient database as well. Remember that in any application, the slowest part will be the database. The database has to pore through millions of records, manage transactions, and send that data across a network. If you design an application to be efficient at the expense of database design, then there is no way you can magically speed up the performance of the database.