This is part one of a three-part series in which I will discuss the architecture of a native Enterprise Vacation Requests application and its potential for being reused with other enterprise applications. We’ll also revisit this topic in later posts to develop something similar in HTML5, and then assess the degree to which we could meet the original app requirements differences between the two architectures.
The Vacation Request / Annual Leave Booking Application
Figure 1 – The work-in-progress Enterprise Vacation Requests application
John and I were asked to develop an application that allows employees to request time off (“vacation” if you’re in North America or “annual leave” if you’re British!) and managers could approve those requests.
We set about thinking of requirements and the kind of user experience we wanted to create, and we thought about our SDK choices and which might be the best fit for this application, and concluded it might be interesting to develop at least two versions of the application ─ the first using the full native SDK, and the second HTML5. This would allow us to compare the two developer experiences and end results.
We’re still working on the Cascades/native version of the application (see Figure 1) and plan to release the source code for it when we’ve finished. But there are already some interesting things emerging which we’d like to share with you.
Below are some of the basic requirements of the application:
Users must be able to submit vacation requests.
Users must be able to modify vacation request details.
Users must be able to cancel vacation bookings.
The GUI must inform the user of their annual entitlement to holidays/vacations and the number of days used so far.
Managers must be able to receive and either approve or reject vacation requests from their employees.
It must be possible to use the application with no apparent impact to the user when there is no network coverage of any sort (“off-line use”).
Integration with a particular enterprise’s back-end system should require changes in only clearly designated parts of the application architecture
The sixth and seventh requirements were particularly influential in driving us toward our architecture. It’s easy to imagine that these requirements might apply to other enterprise mobile applications, which is why we suspect our architecture could be reusable across many scenarios.
So what does our architecture look like?
Figure 2 – Architecture block diagram for the Enterprise Vacation Requests application
Described at a high level, the the application has two primary parts: a Graphical User Interface (GUI) application and a headless service. (Stay tuned for part two of this series, where I will describe how these two work together.)
There’s also something called an “Adapter Framework,” some “queues,” an internal API called the “Operations API” and messages flowing around which we termed “operations.” You can also see that the BlackBerry 10 Hub plays a role.
The Adapter Framework
Figure 3 – The Adapter Framework
We wanted to ensure that the application could work with “any” company’s back-end systems. In reality, there is no technological magic which would allow our application to “just work” with any conceivable set of back-end enterprise systems without the application or some server-side counterpart being changed in some way, so our approach was to isolate the part of the architecture concerned with back-end interactions and give it a well-defined, abstract interface that the remainder of the application would use. Internally, this component would then need to implement the operations corresponding to that logical, abstract interface in a way which made the necessary possible interactions with specific back-end systems in use at a specific company. In other words, its job is to make our logical interface compatible with a real set of concrete, back-end systems through some form of transformation process. In the world of software engineering “design patterns,” a component of this type is called an “adapter,” so that’s the term we used as well.
The idea then, is that to use our application at a particular company, a developer would implement an adapter component which conforms to our abstract interface and plug it into the framework we provided. To make that as easy as possible, we made the adapter a shared library (John will discuss this further in his future blog post).
In theory, anything is possible. It’s easy to envision particular adapters that utilize SOAP/XML or REST based web services for integration and leverage BlackBerry Push or Email for delivering updates from the back end systems.
Up Next: Part Two
In the next part of this series, I’m going to review the remaining parts of the architecture in detail, one at a time.
If you have any questions so far, let us know in the comments below or contact me on Twitter.
functioning of the site, while others are to help us understand how you use it. Read more here about our cookies, and how you can