Software architecture

The software development as a field has seen a significant improvement since the earlier ages. In fact, in a short, some significant changes have been made in the programming field and methods of developing systems. I would like to present a brief history before discussion software architecture.
– Monolithic applications: these were client-based application where both the application and the data sources (databases or files) were deployed to the users machines. As the Fox Pro and MS Access applications, at that period these were the only possible way to develop and deploy application.  The issue with this model is that it took long time to build such applications with no code reusability. Every part of the program written was specific to that application.
– OOP: This was a great advance in the software development with new notions as encapsulation, polymorphism, sub-classing …etc. The code written in OOP had the reusability characteristic, however the major issue is that the code was static. i.e. if the software-application were changer, I had to be re-deployed to all clients’ machines.
– COM: Components: Microsoft provided this approach initially and the software application was built upon different components. The components were fully reusable with two main features: Location Transparency and Tight coupling. However, the major issue was that this approach worked fine for single machine the scaling was a big issue. i.e. even if many machines in a networked used that application, each machine had its own copy of the COM component.
– DCOM: This was the network version of the COM, were all the components were deployed in a network shared location and all the applications in different machines consumes the same version of the component. This was considered as the biggest failure of Microsoft as the not at all reliable and scalable and it only applied to local network.
– COM+: this was the fusion of DCOM and MTS (transaction services) characterized by Object pooling and JIT activation.
– .Net applications: Distributed applications were written with .Net remoting and it took the advantage of the .Net name spaces and rich classes in addition to the networking and distributed application. Here again the issue was that it was only restricted to local networks.
– Web Services: This was a great jump in software development field, it provided object functionalities over HTTP protocol and the data was exchanged using the XML standard, hence it allowed the interoperability of applications (Web service written in .Net can be used by Java Applications). It was based on SOAP protocol.
– WCF applications: this is the Microsoft’s implementation of SOA, which is also the next generation of Web Services. It supports message sending not only over HTTP but also TCP, Named Pipes and MSMQ. It allows developers to send message in different format (SOAP, Representation State Transfer REST and Plain old XML POX).

This is a general overview of the software development technics, architectures and methods. I would like to discuss in more details the SOA applications.
Service oriented architecture is a new way of designing and developing applications. As mentioned by Bieberstein  “SOA adoption probably stems from its link IT and Business, it consists a bridge between the two camps. In the earlier ages of computing, IT people spoke secret language and knew how to operate magical business machines” (Bieberstein et.al. 2008). SOA is in fact a set of technics and methods but mostly thoughts on how to design and develop software-system based on some golden rules as reusability, interoperability, security, consistency…etc. It allows completely re-designing and reviewing how systems are being building and interact in modern computing. The SOA architecture implies considering the following architectural challenges:

1- Services define both Systems and business process: Systems and business process became intertwined and it’s no longer possible to design one without altering the other, they both have to be built at the same time and building the correct Service-Oriented architecture is not a matter of technical skills, it also requires business expertise(Lawler.et.al, 2008).
2- We don’t build SOA from scratch: The businesses might already have some software-applications running during the transition to SOA time. One important aspects of SOA is that we won’t disturb the business operations while building our architecture; we aim to evolve to SOA and not building solutions from scratch.
3- SOA is a vision that requires a consistent interpretation: The implementation of SOA will happen progressively, project by project. Today’s services must satisfy tomorrow needs and leverage systems and services developed in the past. Coordination and planning across multiple projects
4- SOA is in a distributed system: SOA solutions must satisfy all the requirements for distributed systems as security, granularity, communication delays, monitoring …etc (Brown, 2008).

I’ve been developing services with WCF (Windows communication foundations) platform since 2010, and for one who came from the .Net programming I felt at ease at the beginning with platform and different possibilities allowed by the .Net rich classes and namespaces. However, I quickly understood that I had to change my view and way of imagining and designing solution. It was completely different than the ‘classic’ applications I was involving in. Most of components existed somewhere else, we had to consume them using exact and precise contracts and we developed our new services not only to perform what is expected internally but also to follow the different standards and rules of building correct services. One aspect very important when we wrote services, is that we were not allowed to change the service protocols and interfaces as this was already being used by many other applications and services and if we did that, we broke many of them. If a new version of the service was required, we had to create this as a separate service and maintain both of them.

My personal opinion about pros and cons of the SOA is the following: I think that the SOA is a great architecture to quickly and efficiently build business applications with full interoperability allowing exchanging data and information between different information systems without caring about the technology used or the hosting environment. It also creates a great level of reusability of components and objects. However, the major issue is that it creates an important dependency of systems and this dependency will create a risk for others. I would provide an example of currency change service, if the company providing this service stops it, all the travel agencies and other sites or financial applications using this service will be down.

References:

– Norbert Bieberstein, Robert Laird, Keith Jones, Tilak Mitra (2008). Executing SOA: A Practical Guide for the Service-Oriented Architect. ISBN: 0-13-235374-1.

– Paul C. Brown (2008). Implementing SOA: Total Architecture in Practice. ISBN: 0-321-50472-0.

– James P. Lawler, H. Howell-Barber (2008). Service-Oriented Architecture: SOA Strategy, Methodology, and Technology. ISBN: 978-1-4200-4500-0.