Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
If you’re developing applications within the context of ERP – especially if your company is presently transitioning to ERP – it’s essential that lots of thought go into the choice of architecture that will best serve your application development effort. It’s not enough to implement a distributed architecture; serving remote clients, bringing up web apps and integrating old in-house apps with newer ones mean you have a number of choices about exactly how to go about revising your application architecture. There are lots of good choices, and lots of bad ones.
The best place to start is to have a sense of what your choices are, and then give thought to which architecture will most benefit your applications and users’ needs. Before diving into the choices, it’s good to have a sense of the strengths and weakness of distributed architecture in general.
The Upside and Downside of Distributed Architectures
Developers who have made the distributed architecture transition will tell you that there are some unexpected advantages. Distributed architectures can make your applications more scalable, not less; you wouldn’t think so, but that’s often how it turns out (especially in a multi-tiered architecture). You can also please more users with less effort using a distributed architecture, because it’s easier to design an app to cross-functional boundaries and be accessible to a greater number of users, and to write it in such a way that it can interact with a larger pool of other applications.
Finally, in this age of rapid expansion, distributed architectures can often enable you to deploy your application components on any physical app server available to you, and this can be a vital efficiency point if you have a very large number of users and need to factor in load balance.
On the other hand, distributed architectures make every aspect of development more complex, from design to implementation to testing to maintenance. There’s simply more to keep track of – don’t use a distributed architecture unless it’s really beneficial to your users to do so!
Before looking at the possible architectures, let’s look at the questions that differentiate them:
- Is the app a web app, or will the web be the primary mode of access for remote clients? If your development is web-specific, or if the primary user interface is web-specific, then you can safely base your architecture on a web tier.
- Will there be many users simultaneously accessing small amounts of data, or a moderate number of users simultaneously accessing large amounts of data? This determines your data access strategy. The architectural concern will be your mode of data transport to-and-from your databases: should you use object-oriented data containers? Should you be SQL-based? Is persistence important to your app?
- How important is database portability? To what degree will your app, or components you’re designing that will be used by future apps, be dealing with data sources that could change?
- How dynamic will future development be? Does business logic need to be isolated from data access, and presentation isolated from both? Not all architectures facilitate abstraction between data access and business logic. Are you developing apps with components that will be used again for diverse purposes by a wide range of users?
If you have answers to these questions, you can home in on a general idea of what architecture you should use. Here are some of the most prominent enterprise architectures available to you:
General distributed framework with isolated business objects. This structure is simple and does not anticipate a proliferation of remote client access methods. Your app presents as a web app to remote clients, and its primary distribution characteristic is that business logic is objectified as reusable components, to aid in application mobility (i.e., your app components can execute on any server). In addition, your app can be customized user-to-user because of the isolation of the business logic and the freedom with which you can access components, since they are not directly tied to your web layer.
General distributed framework with remote OO data transport. In this scheme, you have several prominent features. First, you are anticipating a broad range of remote clients, and your app will have multiple interfaces to accommodate them. Your response? To use an object-oriented data transport mechanism (EJB or JDO, for example, if you’re using J2EE), rather than query-based interface. Second, you need to create a tier/layer in your design specifically for these objects: it will sit beneath your remote client presentation server (sometimes a web server but not necessarily) and above your application server. Why? It gives you separability between physical and logical data object access, meaning you can fine-tune the match between OO data objects and the components that access them (it will also create some overhead between the business components of your apps and means of handling remote calls efficiently).
Web-specific framework with web services interface layer. Originally a Java architecture, this concept is very useful when remote clients accessing an app have unknown platforms and software services (in the case of Java, for instance, the server side would be J2EE but the remote clients would not have Java Virtual Machine, RMI, java beans capability, etc.). Having a web services layer available for such clients (driven by open protocols like SOAP) beans that a C++ app interface can talk to Java business components. Having web services protocols in place opens your app to an entirely new level of “distributedness,” and does not confine your architecture otherwise. You can mix and match the “web services” layer with other architectural approaches.
These three are not the entire distributed architecture universe, but space precludes an exhaustive presentation. The bottom line is that you have a lot of paths you can take, and the right combination of architectural features will deliver the greatest efficiency and satisfaction of user needs. Whether a perfect solution is out there or not, it’s important from the outset to be thinking in this direction.
