Chapter 4. An enterprise app, Play-style
- Recalling what an enterprise application is
- Determining today’s enterprise application challenges
- Understanding Play applications in an enterprise context
- Defining our warehouse enterprise application
In this chapter, we’ll review what an enterprise application is. We’ll then explain what challenges enterprise applications face today. We’ll also see how the Play framework can be used to create enterprise applications. From there, we’ll architect the warehouse application we’re going to implement throughout the book and put the application in an enterprise context.
4.1. Recalling what an enterprise application is
An enterprise application is usually a business application. Its purpose is to meet specific business requirements. It encodes business policies, processes, rules, and entities; is developed in a business organization; and is deployed in a manner responsive to business needs.
In today’s corporate environment, enterprise applications are complex, scalable, distributed, component-based, and often mission critical. They are data-centric and must meet stringent requirements for security, administration, and maintenance. Most of the time, business applications are isolated. One enterprise application addresses business requirements for one specific business unit. But because of isolation and business constraints, most enterprise applications are unable to talk to each other. It’s usual to see multiple business applications performing similar tasks because of that.
Enterprise applications usually live inside the IT department and are usually hosted within the organization.
Current enterprise applications are applications that are created to fulfill a business need such as IT service management, customer-relationship management, enterprise-resource planning, business intelligence, project management, collaboration, human-resource management, manufacturing, enterprise-application integration, and so on.
Figure 4.1 illustrates a typical enterprise application ecosystem.
Figure 4.1. Enterprise application ecosystem
CRM: Customer Relationship Management
ERP: Enterprise Resource Planning
ECM: Enterprise Content Management
As we can see, because an enterprise application is secured and usually satisfies one business need, it’s isolated and confined within its business context. It’s also not exposed to the outside world, and the information it holds is not accessible by other systems. Because of that, often new business applications are built to gather information from the different systems and to distribute that information to other business applications.
Usually, these types of applications operate by batch during the night. For example, a batch is run every night to gather new customers from the CRM system and to feed the billing system. It allows the applications to stay isolated (as are their respective business units). Often, user interfaces are as complex as the applications, because little time was left to think about the users.
Integration with the existing systems is key. Most often, this isn’t really part of the application requirements; it tends to be added along the way, leading to very complex and difficult-to-maintain architectures. Scalability also becomes a problem. Figure 4.2 illustrates a typical enterprise application system once integration has been performed.
Figure 4.2. Enterprise application ecosystem after integration
CRM: Customer Relationship Management
ERP: Enterprise Resource Planning
ECM: Enterprise Content Management
As we can see, there is no real interaction between the systems per se. Most of the time, one application goes straight to another application’s datasource. This leads to the following problems:
- Strong coupling, making it hard to update or upgrade applications
- No separation of concerns—the CRM application can now decide to act as an ERP
- Data-integrity problems
Nowadays, enterprise applications tend to be developed and architected with a new concept in mind: service-oriented architecture. The idea is that each application should be designed as a service. This allows for:
Service-oriented architecture (SOA) is a software design and software architecture design pattern based on structured collections of discrete software modules, known as services, that collectively provide the complete functionality of a large software application. The purpose of SOA is to allow easy cooperation of a large number of applications that are connected over a network.
The most common implementations are done though the so-called ESB (enterprise service bus). Each service communicates through messages. An ESB usually performs the following tasks:
- Monitor and control routing of message exchange between services
- Control deployment and versioning of services
- Ensure reusability of services
- Provide commodity services like event handling, data transformation, message and event queuing, and security or exception handling
Figure 4.3 illustrates a typical SOA implementation of the applications from the previous figure.
Figure 4.3. Enterprise applications with SOA
CRM: Customer Relationship Management
ERP: Enterprise Resource Planning
ECM: Enterprise Content Management
SOA is relatively new in enterprises. The main drawback is complexity due to the abundance of configurations and implementation details. The fact is that extra effort to maintain all the services is required. Most of the time communication between the different services happens through message exchange. Extra care is required to design the message exchange flow and message composition. SOA is also most often not web compliant, meaning that exposing services over the web still requires extra effort.
Obviously, something new is starting to change this status quo: the web. This is a game changer for enterprise applications, and it brings new challenges.
4.2. Determining today’s enterprise application challenges
It seems natural today to request information and get it immediately. The internet has changed our everyday life. If we want to know what time a flight from Singapore arrives, we can connect to the airport website and get immediate results. We don’t need to wait one or two hours to have the information. Even better, information is pushed to us; our phones can alert us when important (or not so important) events occur. For example, our phones can tell us as soon as the Celtics win the NBA tournament. Applications are reactive.
As users, we’re now used to coping with multiple flows of information. We are no longer pulling information; now information is pushed at us.
A user’s interaction with an IT system has also changed dramatically. We don’t need to read a user manual before using a hotel reservation system, nor do we need a training session. Software is now accessible and usable by everyone.
Because the software is easily reachable and accessible, users can add more and more information to the different systems, creating more and more data. Today, we’re dealing with a large quantity of information.
With such a large amount of information, most internet web applications provide a way to query that information through a public API, allowing third parties to combine that information and redistribute it in real time.Web applications talk to each other in real time.
Simplicity is also key. Most of the popular web applications focus on one problem and provide a simple solution. Enterprise applications should learn from them. Concentrate on your business problem and stay simple. This doesn’t mean that the application is simple in itself; it means that the application can be easy to use and to extend.
Scalability is usually a strong requirement for an enterprise. But talking about enterprise scalability is not the same as talking about web-application scalability. In the latter case, we usually mean that the application can handle millions of users. Enterprise scalability means that the applications should be able to grow with enterprise needs. This can be in terms of users, but it also means that the applications should be able to scale to new business requirements. For example, if company X acquires company Z, the address book application from company X should be able to absorb company Z’s address book. Scalability is a matter of supporting more users and more data but also integrating more systems. Cloud computing helps with the first part, and simple architecture and good APIs help in the second case. Again, modern web applications provide for these two requirements naturally.
You probably agree that all of this is now a given when we talk about web applications. But enterprise applications rarely meet these requirements. And as you guessed, enterprise has to address these challenges to stay on the competitive edge:
- Push real-time data to their customers/employees
- Deal with a large flow of data
- Improve scalability and integration
- Provide easy integration with the latest clients
- Ensure interoperability between applications and existing systems
The internet, HTML5, XML, JSON, and the HTTP protocol (and good developers) provide most of the low-level requirements to address these challenges, as we’ll see in the next chapters. There’s also a paradigm shift in which client-side programs are becoming more and more elaborate due to the hardware evolution; for example, your phone is more powerful than your two-year-old desktop computer. Enterprise will adapt to this new paradigm as well.
In enterprise, the main challenge is to aggregate and redistribute selected data to other systems or users. Usually the needed information is dispatched over multiple systems, and one needs to aggregate them. Because we’re dealing always with more and more information, processing large amounts of data in real time will be the next big requirement. Another implicit requirement is overall simplicity and the tool’s simplicity. The systems we’re building should be comprehensive, and the tooling should make it easier for us to build a great system, removing complexity from our way. The Play framework certainly meets that requirement. Building simple software blocks allows us to create reliable and complex systems that match business needs. A modern framework should be able to help address the mentioned challenges. Obviously, we’ll discover through the book that Play addresses exactly those challenges; but first, let’s see how Play’s application architecture should work in an enterprise context.
4.3. Understanding Play’s application in an enterprise context
As we already explained in chapter 1, Play is a web framework that focuses on the following aspects:
- Simplicity
- High productivity
- Modern web application development
Simplicity doesn’t mean that you can only build simple applications. On the contrary, it means that it should be easier to integrate your application components. The idea is to decompose your complex application with simple building blocks. Each building block should be simple enough that it’s comprehensible by everyone without much thinking. It also allows new developers to join a project and be productive from the start without losing time setting up the environment or understanding the details of the other blocks.
High productivity means that any developers can produce working software within a matter of hours and can be able to demo it without external help.
Modern web framework means that the framework concentrates on the server side and delegates as much as possible to the (rich) clients. Play makes sure to delegate as much as possible to the web browser and allows easy integration with the latest browser specifications. Today, a lot of innovation happens at the client level. Our smartphones are now more powerful than the desktop computers of two years ago. Therefore, the server should delegate as much as possible to the clients. The less the server does for the client (for example, rendering or user-interface interaction), the more scalable the application is.
Play is also designed to easily integrate with other web applications through HTTP. Play forces you to think about the way your clients will interact with your applications. It also provides functionality to easily talk to other web applications.
How do such concepts fit the enterprise context? If you see the web as a giant company and the different web applications as business units, everything is explained. A lot of web applications are able to get data from other web applications. For example, most new web applications allow you to log in using your existing Facebook credentials; you don’t need to reimplement user authentication. Let’s see in more detail what we mean and how Play helps.
Play achieves reusability and interoperability between applications by promoting RESTful architecture web applications. This means that web applications should expose their methods and data using REST, and most of the time they should expose themselves as web services as well.
A RESTful web application is a web application implemented using HTTP and REST principles. It’s a collection of resources, with four defined aspects:
- The base URI for the web application, such as http://example.com/warehouses/
- The internet media type of the data supported by the web API
- The set of operations supported by the web API using HTTP methods (for example, GET, PUT, POST, or DELETE)
- A hypertext-driven API (that is, URLs define the API)
In order to facilitate communication within a web application, web APIs are usually part of the web application. REST promotes reusing the existing information systems. This means that web REST APIs tend to reuse the same architecture, making it easier for developers.
RESTful architecture goals are:
- Scalability of component interactions
- Generality of interfaces
- Independent deployment of components
- Intermediary components to reduce latency, enforce security, and encapsulate legacy systems
If we translate this into enterprise terms, it means greater interoperability between applications, standard ways to produce interfaces using predefined operations (for example, GET, PUT, POST, or DELETE), and loose coupling between components. This is exactly what enterprise applications are looking for.
The REST architectural style describes six architectural constraints:
- Client–server— A uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers aren’t concerned with the user interface or user state, so servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface between them isn’t altered.
- Stateless— The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client.
- Cacheable— As on the World Wide Web, clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable or not to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.
- Layered system— A client can’t ordinarily tell whether it’s connected directly to the end server or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches.
- Code on demand (optional)— Servers can temporarily extend or customize the functionality of a client by sending executable code. Examples of this include client-side scripts such as JavaScript.
- Uniform interface— The uniform interface between clients and servers, discussed ahead, simplifies and decouples the architecture, which enables each part to evolve independently.
Complying with these constraints and conforming to the REST architectural style enables any kind of distributed hypermedia system to have desirable emergent properties, such as performance, scalability, simplicity, modifiability, visibility, portability, and reliability. The nature of Play enforces these principles, which means it has never been easier to implement a RESTful web application than with Play.
Going back to an enterprise context, when creating a new application, on a high level, we want to:
- Reuse existing software blocks
- Retrieve data from other systems
- Expose data to other systems
We saw that Play promotes the REST architectural style, which provides exactly the elements discussed and at the same time focuses on simplicity and reusing the existing information systems. Figure 4.4 shows how our enterprise applications would look using the REST-style architecture.
Figure 4.4. Enterprise applications with Play
CRM: Customer Relationship Management
ERP: Enterprise Resource Planning
ECM: Enterprise Content Management
With Play, each enterprise application is a web application, and each enterprise application provides a REST web API. Enterprise applications communicate with each other using a RESTful web API through HTTP. The REST web API comes naturally when designing the web application. The web application architectural design is therefore key. We’ll see in the next section how that all works when we architect our warehouse application. Typically, communication between the different applications occurs via HTTP, exchanging JSON, XML, or whatever format the developers agreed upon.
On a more practical level, enterprise tends to have large development teams. Distributing the work between the different teams is therefore key. Play provides two ways to achieve that goal:
- Create a Play module or Play sub-application for each team
- Create a web application (a.k.a., a web service)
A Play module or Play sub-application is a web application within your Play web application. For our discussion, it’s important to know that modules allow you to build a subset of an application, and chapter 11 explains in more detail how to create modules and sub-applications. Again, the REST-style architecture allows the teams to agree on communication between the different application modules. Obviously, defining the interface to communicate between the applications is the most important part; that’s why you usually need a web service API that follows the REST architecture, and Play makes it easy to include.
Using Play, it’s also easier to build real-time web applications, query multiple systems, and deal with large amounts of data, thanks to its asynchronous nature. We’ll detail this in chapter 9.
As we’ve already seen in chapter 1, Play focuses on simplicity, allowing the developers to concentrate on the business problem at hand instead of fighting or configuring the framework.
The only drawback of the REST-style approach is that it’s crucial to correctly design the application’s data flow and the REST-style architecture. Happily, Play is here and it provides all the tools to do so. The next section outlines how to architect our warehouse enterprise application based on what we’ve learned.
4.4. Defining our warehouse enterprise application
Through the next chapters, we’ll design and create our warehouse enterprise application. A warehouse application is an application that manages diverse products. A product is identified by a unique EAN number. Within the warehouse, we want to know how many products there are. We also want to make sure that we can record a product leaving or entering the warehouse. The application must:
- Add products
- Edit products
- View products
- View current product’s stock
- Add a certain quantity of product X to this warehouse
- Subtract a certain quantity of product X from this warehouse
Our system is only required to interact with humans; this means we’ll serve HTML to our web browser and the client will send back HTML forms.
Following the advice in the previous sections, we can model what our URLs and our web application calls are going to be:
Applying HTTP verbs, we want to expose the following:
We can see that the last two rules are a bit different in the sense that the URL takes the quantity parameter. This is because URLs should be idempotent; that is, they always return the same value for a given URL (in mathematics, idempotent means not changed in value following multiplication by itself). With the interface we defined, we’re able to split the work between two teams easily. One team can develop the product part while the other one can concentrate on managing the stock items. Other systems (and other teams) can already simulate the use of the interface, as we’re only returning simple and agreed-upon data messages.
For example, to create a new product, we would issue the following using our browser:
Request URL:/products/ Request Method:POST Request Body: ------WebKitFormBoundaryllSQqb38u5oy6 Content-Disposition: form-data; name="ean" 1234567891012 ------WebKitFormBoundaryllSQqb38u5oy6Kc8 Content-Disposition: form-data; name="name" Item ------WebKitFormBoundaryllSQqb38u5oy6Kc8 Content-Disposition: form-data; name="description" A new item ------WebKitFormBoundaryllSQqb38u5oy6Kc8--
And we’ll get the following back from the server:
HTTP/1.1 201 Created Location: /product/123456789101 Content-Length: 0
Now if we want to expose our application as a web service, we’ll probably have the following URLs as well:
POST /api/v1/product/
GET /api/v1/product/${id}
POST /api/v1/product/${id}
DELETE /api/v1/product/${id}
GET /api/v1/products/
GET /api/v1/stockitems/
POST /api/v1/product/${id}?quantity=${qty}
You’ll notice that we prefix our calls by a version number that we expose through the /api resource. This is because other systems can then refer to this unique URL without any fear that the version will change. It allows our API to live its own life without impacting the rest of the application. Our application would then interact with other systems. This means we would serve XML, for example, and interpret XML. Note that we could decide to stay with HTTP, but that wouldn’t be practical for the other system involved. In the case of a web service, we’re only interested in the business data and not how to represent them.
This means that if we issue the following:
Request URL:/products/
Request Method:POST
Request Body:
<?xml version='1.0' encoding='utf-8'?>
<product ean="123456789101" name="item"
description="an item"/>
The server responds with:
HTTP/1.1 201 Created
Location: /product/123456789101
Content-Length: 102
<?xml version='1.0' encoding='utf-8'?>
<product ean="123456789101" name="item"
description="an item"/>
As you can see, this is the same behavior; only the exchange protocol changes. XML is usually easy to transform, and any system can then modify it for other application needs. The big advantage of such an interface is that your application is now able to communicate with others. This means that another application in your enterprise can act as a client and request information from the warehouse application. And because Play is asynchronous by nature, Play applications can request multiple pieces of information at the same time while combining and transforming the results as they’re available.
4.5. Summary
In this chapter, we explained what an enterprise application is and how it differs from other applications. We saw different types of architecture that allow enterprise applications to communicate. We identified the upcoming enterprise challenges and quickly saw how Play proposes to address them. We then saw how Play fits into an enterprise environment and, by using the RESTful principles, how enterprise applications can communicate simply and effectively. We also learned how to decompose our applications so that several teams can work in parallel.
We then focused on the application we’ll build throughout the book and how to build an interface so that internal and external systems can communicate with it. In the next chapter, we’re going to implement this interface. We’ll make it concrete by explaining how controllers work in Play.