What Is a Distributed Application?

A distributed application is an application comprised of multiple clients that communicate with servers or machines through a network.

In this blog, we look at how distributed applications can be used, which architectures work best for distributed applications, when and when not to use this approach, and the tools and technologies that can help build distributed systems.

How Can Distributed Applications Be Used?

Distributed applications can be used in a variety ways, from eCommerce platforms to desktop applications. When it comes to leveraging or applying a distributed architecture to you really need to understand which type of system you want to apply to your application.

Before even attempting to decide to which architecture your application is suited for you really need a proper plan of a conceptual breakdown. That will far outweigh any technologies or architecture you desire to use. So which kinds of distributed applications can developers create? Let's look at a few examples.

Distributed Application Examples

For distributed applications there are three main application architectures, the client-server architecture, broker pattern or service-oriented architecture. Now obviously there are many ways to produce a client-server distributed application from a two-tier system to a multi-tier system with n number of tiers.

Based on whatever level of requirements you need to achieve will depend greatly on the route you choose. As for broker pattern, there is really one major technique to produce them called the Common Object Request Broker Architecture (CORBA) method. While the service-oriented architecture (SOA) design is really a combination of both the broker and client-server architecture.

Client-Server Architecture

Before we get into exactly what different tier systems that are involved with client-server architecture, first we need to understand. What does it entail to create client server architecture for a Java application? The simplest way to have the design of a client server architecture, is to have framework that is segmented into different tasks or workloads that are provided by either a service or a request that are either the server or the service requester (client).

Hence, the name client-server architecture where you have the client who on one side is creating some request in which the server acts as the function of the requests and completes the task. In this scenario, the client is facilitating all communication with the server side therefore the client side does not share any reasons with other clients.

Broker Pattern Architecture

So, what is a broker pattern? Basically, a broker pattern application is a distributed system using decoupled components that interact with each other using remote service calls. What makes broker patterns unique is the broker component, which coordinates the communication of the decoupled components. When a client requests a task in an application, the broker receives that task or service and in turn redirects the task to the appropriate server to execute the task.

The main way achieve this design is to create what is called a CORBA. CORBA is a standard practice that is defined by the object management group (OMG) where they help facilitate the communications of technologies for these complex systems.

Service-Oriented Architecture

SOA is a design strategy in which applications use services that are available in the network. Each of those services can be formed together to create an application. SOA does have necessary requirements of the following:

• Standardized service contract
• Loose coupling
• Abstraction
• Reusability
• Autonomy
• Discoverability
• Composability

The requirements above describe the components that make up a SOA. But there are also different roles defined by a SOA application. Those roles can range but in general most are three roles of the service provider, service consumer/requester and service broker.

📚 Further Reading: Microservices vs. SOA for Java Applications 

The roles are pretty self-explanatory but the service provider acts as producer of the information to the service registry, the service broker helps to ensure that the information from the service provider is available to the service consumer. Basically, the responsibilities become a hybrid of both structures where the client-server now has a slightly decoupled service that acts as the broker.

When and When Not to Use a Distributed Application Architecture

Not all application architectures use a distributed application architecture therefore there must be some drawbacks, right? Of course, there is and of course there are some major benefits as well. Determining those pros and cons are obvious why application architectures have so much responsibility.

When to Use a Distributed Application Architecture

Distributed application architecture provides a ton benefits to your application that include scalability, resiliency, resource sharing, flexibility, and concurrency. Scalability is extremely important in modern day application development eliminating much technical debt by allowing teams use applications at so many levels. Distributed applications will have resiliency, meaning applications can operate continually even if parts of your application fault. 

• Resource sharing
• Openness
• Concurrency
• Scalability
• Fault tolerance

With this architecture an application can stay running but also increase application performance by sharing software and hardware resources allowing for better overhead on a system. With many of these systems acting independently of each it allows for that flexibility of reusing a service or technology or the ability to use the right software or hardware for the job.

Lastly, distributed applications allow for consistent changes and updates so application versions are more iterative and concurrent.  This leads to better application performance and more frequent update delivery.

When Not to Use a Distributed Application Architecture

In theory, if you could create every application while not using distributed systems at any scaled then your application would be easier, faster and just overall more predictable. However, the reality is that your application will most like need to have some level system load that requires the need split up the application.

Now this is definitely going to present some problems because the level of complexity and just overall design will inherently make an application difficult to create. Whereas an non-distributed application may be much more simplistic and require much less troubleshooting.

Anytime that an application is sending any information from one server to another will introduce a level of security concerns. Not to it lightly but if you have an application that does not expect a larger user base as well as worried about security might find that distributing to be not an option. For the most part, standalone applications tend to fall in this category of non-distributed applications.

Tools and Technologies for Building Distributed Java Applications

Building distributed Java can be notoriously difficult and there is a ton of nuance, skill and knowledge that goes into it. However, here are some tools that my provide some help or some interesting assistance in future design plans.

• Docker - Docker is the de-facto standard for containerization
• Kubernetes - Kubernetes is the de-facto standard for container orchestration
• JRebel - Skip redeploys during Java development

Final Thoughts

Overall, it is extremely interesting looking at different types of distributed systems and trying to understand what makes sense for you or either now or in the future. With technologies out there that make working with and creating distributed Java applications easier, it's exciting to think of how these systems may evolve.

Redeploys can slow down even the best-organized and developed Java applications. Want to see what Java development is like without redeploys? Try JRebel on your project free for 14 days and see how much time you can save.

Try JRebel Free for 14 Days

Additional Resources

In this webinar from Rod Cope, CTO at Perforce Software, he looks at some of the resilience patterns we mentioned earlier in the article and how they're applied to distributed and microservices-based applications.

Looking for additional insight into distributed applications or microservices applications? The resources below are worth a look.

• Webinar: Making the Move to Microservices
• White Paper: Developer's Guide to Microservices Performance
• Resource Collection: Exploring Java Microservices