Block III: From architecture to product

Unit 10: Building blocks and enterprise architectures

1
 In this unit, you will continue exploring how reuse can
contribute to more productive software development.

 You will learn how larger problems can be solved through

the reuse of existing solutions, such as components and
services, and discover more about how requirements
influence architectural decisions.

 This unit also looks briefly at enterprise architectures for

large organizations and introduces the Java EE framework.

Note that: All SAQs and Exercises in this unit are required.

2
 Section 1: Introduction

 We begin this unit with component-based development (CBD), which

aims to develop systems by assembling them from reusable self-
contained software components.

 Components have two types of interfaces: a provided interface, and a

required interface

 We then look briefly at using objects as components and consider

issues such as the contract between two interacting components and
how this influences whether one component can be replaced by another.

 Components usually rely on a particular technology, and the architect is

normally aware where they are deployed.
◦ We discuss service-oriented architecture (SOA) software, which is
structured simply as a set of services.

3
 Section 1: Introduction

 In this unit we introduce quality attribute scenarios, a way of documenting

what particular quality attributes will mean in practice, in a way that will
help us make architectural decisions.

 This raises the question of what principles software architects can follow
to ensure that various types of quality requirement are met.
◦ For each type of attribute we can describe a set of tactics: reusable
solutions to the problem of achieving particular qualities.

 Finally we look at enterprise architectures: software systems such as

those used by large organisations.
 We briefly introduce Java Platform, Enterprise Edition (Java EE) which is
a framework for constructing enterprise systems and give an example of
how a component and a service can each be implemented in Java EE.
 We end by presenting one possible enterprise architecture for the hotel
system.

4
 Section 2 : Components and interfaces

2.1 Software components

 In earlier units we have used the term component to mean
any more or less self-contained software unit. In this section
a component has a more specific meaning, as a unit of
software structured according to the following principles:

◦ A component encapsulates data and operations.

◦ A component is fully documented and thoroughly tested.
◦ A component’s specification clearly separates the component’s
interface from its implementation.
◦ A component’s specification may include non-functional
characteristics.
◦ A component is known to client components only through its
interface.

5
 Section 2 : Components and interfaces

 Building a software by plugging together off-the-shelf components approach is

known as component-based development (CBD).
Advantages Disadvantages
• Reusing a standard component should • Using standard components may
be cheaper than developing software restrict what we can do since we have
from scratch. to work with the capability of the
• Using off-the-shelf components will components.
allow applications to be developed • Some additional software is likely to be
more quickly. needed as ‘plumbing’.
• Standard components will have been • If the interfaces of components are
used in many other projects, so their incompatible, adapters will have to be
behavior will be well understood and written.
any bugs are likely to be known. • Creating a system by plugging together
• Components are pluggable, so it is off-the-shelf components may not be as
often possible to replace one component simple as it sounds.
with another providing it has the same
interface and behaves in the same way.

6
 Section 2 : Components and interfaces

2.2 Interfaces

 An application built using components is likely to be

structured using call-return architectural style, in which
components interact by making method invocations on one
another.
 A component may have several different interfaces,
representing different points of interconnection.
 Interfaces come in two kinds:
1. Provided interface: A description of a set of operations
a component makes available to other components.
2. Required interface: a description of a set of operations
a component needs from other components.

7
 Section 2 : Components and interfaces

 Once we decide to use a particular component we must also include a

component or components that satisfy its required interface.
 The required interface is also known as the component’s context
dependencies.
 In UML (Figure 2) a component is represented as a stereotyped box and
has two notations: (a) Graphical (b) Textual
 The figure also shows the notation for required and provided interfaces in
both graphical and textual notations.

8
 Section 2 : Components and interfaces

Figure 3 shows a Security component.

By convention, the interface names are prefixed by an upper case ‘I’.

9
 Section 2 : Components and interfaces

Representing interfaces in UML

 An interface is represented by a box marked with the stereotype

«interface».
 The box is similar to the notation for a class but since an interface does not
have attributes the middle compartment is always empty (Figure 4).

10
 Section 2 : Components and interfaces

Example 1
 Figure 5 shows a catalogue component offering a number of services, including some support
for browsing the catalogue and searching for particular products.

 Assuming a client can browse alphabetically or by category of product, and search by entering
a keyword, we could specify the provided interfaces of the component as shown in Figure 6.

11
 Section 2 : Components and interfaces

Interfaces as sets of behavioral assumptions

 The interface of a component might seem to be described fully if we

know the signatures of its operations.
 An interface is much more than this: It will include assertions (pre-
and post conditions and invariants).
 We can use the terms assume and guarantee respectively to mean
the conditions the component needs in order to operate correctly,
and the promises it makes to other components.
 If the assumptions about the environment of the component are true
then the component will meet the guarantees.
 The relationship between a component and its client components
takes the form of a contract.
 This is similar to a contract based on pre- and post conditions but
extending to a wider range of considerations.

12
 Section 2 : Components and interfaces

2.3 Objects as components

 An object in an object-oriented language follows similar

principles to a component and in fact components are often
implemented as objects.

 Components can also be implemented using non-object

oriented technologies but will still communicate through
provided and required interfaces in the same way.

 Components are replaceable: a component can be replaced

by another that does the same job.

13
 Section 2 : Components and interfaces

Exercise 1
What would the assume–guarantee contract for a component include and how
do the assume and guarantee relate to the component’s provided and required
interfaces?
Solution
The contract for a component would be:
1. the pre- and post condition of all the operations in the provided interface of the
component
2. the invariants that apply to any publicly visible properties of the component
3. the required interface of the component and all the assumptions of the required
interface
4. any other assumptions about the environment in which the component will
operate.
The assume would be the preconditions of the operations, and items 3 and 4 of the
contract above.
The guarantee would be the post condition of the operations and item 2 of the
contract above.

14
 Section 2 : Components and interfaces

Exercise 2
Suppose component X is replaced by component Y, which has different
assumptions and guarantees from X. Drawing on your knowledge of design by
contract (DbC) suggest what restrictions must apply to the assume and
guarantee if Y is to be an acceptable replacement for X. Illustrate your answer
with an example.

Solution
The assumptions made by Y must be the same as those made by X, or weaker. The
guarantee Y makes must be the same as the one X makes, or stronger. In other
words Y must not demand more, or deliver less, than X.

For example X might accept up to a million items and promise to process them with
99 per cent accuracy. If Y restricts the maximum to half a million items it is
demanding more. If it promises only 90 per cent accuracy it is delivering less.

15
 Section 2 : Components and interfaces

Interacting components

 When two components interact, one is a client for an operation

supplied by the other.
 The operation is part of the client's required interface and the
supplier's provided interface.
 Often the interaction will follow a call-return style, although other
types of communication are possible.
 If we are using DbC, then before calling the operation the client
must ensure that the preconditions of the operation are met and that
the supplier's other assumptions are also satisfied.
 If we are not following strict DbC, then theoretically a client does not
have to ensure the precondition.
 However, if the precondition is not satisfied then it is unlikely that
something good will happen as a result of invoking the operation.

16
 Section 2 : Components and interfaces

Integration and adapters

 Sometimes a component-based system needs to incorporate other

software that doesn't follow the component model.

 For example we might want to reuse items of legacy software rather than
go to the expense of replacing them.
 In these cases it is possible to write an adapter that gives the software a
provided and required interface.

 The possibility of writing adapters increases the potential for software

reuse.

 An adapter is also often called a wrapper

17
 Section 2 : Components and interfaces

2.4 Summary of section

 In this section you were first introduced to component-based development,

which structures software by combining reusable self-contained elements
that hide their implementation behind interfaces.
 You saw how components and their interfaces can be shown in UML.
 You saw that a component can be described by a set of conditions that it
needs in order to operate correctly and a set of promises it makes to other
components; together they form an assume–guarantee contract
 You then learnt about objects as components and saw how client
components interact with supplier components, through the required
interface of the first and the provided interface of the other.
 Finally you learnt that even software not originally written to be a
component can often be integrated into a component-based system by
wrapping it with an adapter that provides appropriate interfaces.

18
 Section 3 : Service-oriented architecture

3.1 Services

 There are many definitions of a service but we shall use the

following:

A service is an abstract description of some unit of business

functionality, usually described in terms that are meaningful
from both a business and a technical perspective.

 In order to be used, a service must be implemented by a service

provider, and accessed over a network by a client (service
consumer or service requester).
 By combining a set of services it is possible to build applications
and structuring them as service-oriented architecture (SOA).

19
 Section 3 : Service-oriented architecture

Services versus components

Similarities

Like components, services:

• have well defined interfaces which specify how other software can
interact with them
• aim to be loosely coupled, by not exposing details of their
implementation, thus allowing it to be changed without disturbing other
parts of the system
• can be composed – services can be combined to build up more
complex functionality
• aim to be reusable, so that the same service can be used as part of
many different applications.

20
 Section 3 : Service-oriented architecture

Services versus components

Differences
• Communication with components tends to depend on proprietary technologies, which
restricts interoperability. Services use standard communication protocols, which allows them
to interoperate in a platform- and language-independent way.

• Services are discoverable. Clients can access a repository to find details of available
services.

• Components run on computers controlled by the organization using them and if many
organizations use a component it executes in multiple locations. A service in contrast
resides on a provider server, typically owned by a different organization, and executes at a
single end-point that all clients communicate with.

• Services should be autonomous and as far as possible independent of other services.

• So, for example, they do not have a ‘requires’ interface. This is so that they can be
more reusable and also more insulated from changes in their operating environment.
Not all dependencies can be avoided of course, for example a service may rely on a
particular database.

21
 Section 3 : Service-oriented architecture

 In addition, services have two properties which may sometimes apply to

components as well:

 Statelessness. A service or component is stateless if it responds to each

request as a ‘one-off’, without retaining any memory of previous requests.
◦ This reduces complexity, because each request can be dealt with in the
same way.

 Location transparency. Clients can use a service without needing to

know its physical location.
◦ The advantage of location transparency is that the service or component
can be moved to a different computer without clients being affected.

22
 Section 3 : Service-oriented architecture

Find, bind and invoke model

 An SOA collaboration typically involves a ‘find, bind and invoke’ cycle as
shown in Figure 7.

23
 Section 3 : Service-oriented architecture

The elements in this model are as follows:

 The consumer.
 The service. Each service has a service description that specifies how the
client can interact with it in addition to the signature of the service.
 The provider, which is the platform on which the service is implemented. It
accepts and executes requests from clients.
 The registry (or locator) which allows clients to find services.

 The service description for each service is published in the registry by the
service provider.
 A consumer queries the registry, to find the details of a particular service or
to discover a service that meets given criteria.
 The registry provides the consumer with the service description and
information that allows it to bind to the service and invoke its operations.

24
 Section 3 : Service-oriented architecture

Kinds of service

 The discussion in this subsection and the following one are based on
Sommerville (2011).

 We can distinguish three kinds of service:

◦ Utility services, which provide some generic functionality useful in a

wide range of applications.

◦ Business services, which implement a specific business function

◦ Coordination services, which coordinate workflows composed of a

number of individual services.

25
 Section 3 : Service-oriented architecture

 Services can also be classified as either task-oriented or entity-oriented

services.
 Task-oriented services are related to business activities (business
processes), whereas entity-oriented services are related to business
entities (business objects).
 Coordination services are, by definition, task oriented, but the other two
kinds of service can be either task- or entity-oriented.
 Examples of these classifications are given in Table 1.

26
 Section 3 : Service-oriented architecture

Composing an application

 When we build an application within an SOA we must choose

suitable services and then compose them into a workflow, so
that the services are invoked in the proper sequence.

 This overall coordination is referred to as service

orchestration, and successful orchestration is obviously
essential to whether or not the application will work.

27
 Section 3 : Service-oriented architecture

 In highly simplified form, developing an application by composing services

within an SOA consists of the following stages, assuming the requirements
are already known:

◦ Design a workflow and specify what services will be needed.

◦ Use the registry to discover candidate services.

◦ From the candidates select a suitable set of services.

◦ Orchestrate the chosen services according to the workflow.

 This may be done using a special-purpose orchestration language, or we may
write an orchestrating program in a standard language such as Java.

◦ Test the application and correct any faults found.

28
 Section 3 : Service-oriented architecture

Advantages of SOA
Service-oriented architecture offers a number of potential advantages
including the following:
• Agile and flexible response. SOA supports a flexible business model that can
respond quickly to changes in customers’ requirements, new business
opportunities or competitive threats. Developers can quickly assemble new
applications by combining existing services.
• Less duplication. If several parts of a business require the same function, it can
be packaged as a service and made available for reuse.
• Integration of legacy applications. Legacy software can be wrapped as a
service and made to interoperate with other applications.
• Use of third-party services. Systems can easily incorporate functions, for
example credit card validation or online payment, provided as services by external
suppliers.
• Language independence. Services written in different languages can
interoperate using standard protocols.

29
 Section 3 : Service-oriented architecture

3.2 Summary of section

 In this section we looked at services. A service is an abstraction of some

unit of business functionality, and service-oriented architecture structures
software as a set of services.

 You next learnt about the ‘find, bind and invoke’ cycle.

 You saw that services can be classified into three types: utility services,
business services and coordination services, and further classified as task
orientated or entity-orientated.

 You learnt that, to compose an application, appropriate services must be

selected and then orchestrated into a workflow, and you read an outline of
the steps needed to develop a system using service-oriented architecture.

 Finally you saw some of the advantages of service-oriented architecture.

30
 Section 4: Architecture, quality attributes and tactics

4.1 Quality attribute scenarios

 In unit 9, we defined quality attributes to be non-functional requirements such as
security, reliability, availability, usability, maintainability, portability, performance, ….
 In this section we will introduce quality attribute scenarios, a tool that allows
specification of non-functional requirements in a more precise and detailed form
which can be used to help make architectural decisions.
 Much of this section draws on the discussion of quality attribute scenarios by Bass
et al. (2003, 2012).
 They define a six-part model which is shown in Figure 8.

31
 Section 4: Architecture, quality attributes and tactics

In this six-part model:

 The source is a human actor, another system, or anything else that can
generate a stimulus.
 The stimulus is any kind of event or request.
 The artefact is what will respond to the stimulus. It might be a running
component or service if we are considering performance for example, but
it could be code or documentation if we are interested in maintainability.
 The environment specifies the conditions which the artefact will be
operating under. For instance if we are concerned with performance the
environment might be either ‘normal operation’ or ‘overloaded’.
 The response is what happens as a result of the artefact receiving the
stimulus.
 The response measure is an objective yardstick by which we can test if
the requirement has been met.

32
 Section 4: Architecture, quality attributes and tactics

 For a given attribute we can list what types of value can occur for each of the six
parts. Table 2 shows the possibilities, including sample metrics, that Bass et al.
give for performance.

33
 Section 4: Architecture, quality attributes and tactics

 A sporadic event is one that is infrequent and isolated.

 A stochastic event is one occurring randomly but according to a well-
defined probability distribution: for example heads coming up when a coin
is flipped.
 Bursty events are ones coming in sudden and unpredictable clusters
overlaying normally low background activity.
 Latency is the time taken to process a stimulus, for example how long
does a search engine take to respond to a query?
 Throughput is the number of events dealt with in a given time.
 Jitter is the amount of variation in latency: for example, are some
responses very quick while others take much longer?
 Miss rate measures the proportion of events that are not responded to,
and data loss measures how much data is lost because the system fails to
record it.

34
 Section 4: Architecture, quality attributes and tactics

Examples of periodic, sporadic and bursty events

 Periodic
◦ Anything that occurs regularly, for example information sent at the same
time each day from a weather station, or status information sent every
minute from a spacecraft.
 Sporadic
◦ Messages sent to an address for reporting problems, or signals from a
device monitoring earth tremors.
 Bursty
◦ Search queries about a suddenly popular topic, or signals from a device
reporting lightning strikes in a particular area.

35
 Section 4: Architecture, quality attributes and tactics

4.3 Tactics for quality attributes

 Quality attribute scenarios specify what qualities the system should

possess but not how they can be achieved.
 For that we turn to design tactics, which are the various choices available
to us when deciding the architecture of a system.
 As an example, if the quality we need to achieve is performance, a
possible tactic is to add more resources to deal with demand.
 This may not always be possible for cost reasons, but it is one of the
options we should consider.
 Tactics are reusable solutions that have emerged from long experience
among software engineers.

36
 Section 4: Architecture, quality attributes and tactics

 Bass et al. (2003, 2012) have led the way in introducing tactics as a form
of reuse and describing tactics for a representative range of quality
attributes, although tactics can be described for any attribute.
 Here we have space to consider only two examples. The ones we chose
are performance and flexibility.

 Performance was chosen because performance was one of the quality

attribute scenarios we explored earlier, so it allows us to show an example
of how quality attribute scenarios and the corresponding tactics are
related.
 Flexibility was selected because it is closely associated with many of the
key concepts of the module. Bass et al. refer to modifiability rather than
flexibility but we shall treat the two terms as meaning the same.

37
 Section 4: Architecture, quality attributes and tactics

 Performance is to do with timing. The system is presented with a stream of

incoming events and should process them to meet quality requirements measured
by latency, deadlines, throughput, and so on.
 Tactics for meeting performance requirements take three main forms
 Tactic 1: Manage demand
How many?
◦ If the frequency of stimuli is controllable, for example if we are periodically
asking a weather station for the current temperature, we can simply sample the
stimuli at a rate the system can keep up with.
◦ Otherwise incoming stimuli are placed in a queue and processed as soon as
possible. The queue will have a maximum length, which in some circumstances
may be exceeded, causing stimuli to be missed, but this is unavoidable since no
system has limitless capacity.
How much?
◦ Processing stimuli requires computations and access to resources – a demand
on the system. Using efficient algorithms and resource requests will reduce this
demand.

38
 Section 4: Architecture, quality attributes and tactics

 Tactic 2: Manage system capacity

◦ Resource provision
 One way to deal with demand is to increase resources: storage, processing or
communications.
 A trade-off is involved since increasing resources has a financial cost.
◦ Bottlenecks
 There may be bottlenecks: widely used resource such as data with only one point of
access, or computations carried out just in a single location.
 If processing stimuli involves such a bottleneck, performance is likely to suffer.
 To overcome this we can provide multiple copies of the data, or run the computation in
multiple locations.
◦ Concurrent processing
 Wherever possible, stimuli should be processed in parallel.
 Even where we do not have multiple processors it is usually possible to process stimuli
in separate interleaved threads of control and so make more effective and efficient use
of resources
 For example by ensuring input and output is not idle, by assigning it to a thread that is
currently ready to use it.

39
 Section 4: Architecture, quality attributes and tactics

 Tactic 3: Match resource to demand (also known as arbitrating

resources)
◦ Resources must be matched to demand in a way that best meets quality
requirements.
 For example, to minimize latency we would use a scheduling policy that deals
with short tasks before lengthier ones – rather like the ‘10 items or fewer’
queue in supermarkets.

◦ If deadline is the measure then each task must have a priority and the
scheduler must ensure that higher-priority tasks are dealt with first.

◦ To achieve throughput the scheduling policy must attempt to maximize

use of resources, which means that, whenever a task cannot make
progress for some reason, resources it is using must be temporarily
reallocated, allowing other tasks to use the slack capacity.

40
 Section 4: Architecture, quality attributes and tactics

 Figure 9 summarizes performance tactics.

41
 Section 4: Architecture, quality attributes and tactics

4.4 Tactics for flexibility

 Flexibility is the ability for software to be changed easily.

 Flexibility is a very important quality, not only in agile

development where frequent changes can be expected, but
also for maintenance of delivered systems.

 Bass et al. (2012) describe four tactics for flexibility (which

they call modifiability).

42
 Section 4: Architecture, quality attributes and tactics

 Tactic 1: Minimize coupling

◦ Coupling is concerned with how much changing one part of the system affects other
parts.
◦ If coupling is low then a change in one place does not have consequences for other parts
of the system.

 Tactic 2: Maximize cohesion

◦ Cohesion measures how closely the activities of a module are related to one another.
◦ Module here could mean any kind of subsystem – a component, a service, an object-
oriented class and so on.
◦ If a module has high cohesion it will group together a set of closely related activities and
exclude unrelated ones.
◦ Its activities will all share a common purpose.
◦ If activities are together within a module they will be less isolated from one another than if
they are part of different modules.
◦ If a module cuts across many different concerns it may need to be changed frequently,
and a change required to one activity in a module may have effects on otherwise
unrelated activities.

43
 Section 4: Architecture, quality attributes and tactics

 Tactic 3: Keep modules small

◦ The idea here is fairly intuitive: if modules are small and a change involves just a single
module it will be relatively easy to make.
◦ However, we need to make sure that we do not separate a group of activities that are
likely to change as a unit.
◦ Otherwise, if a change does need to be made, the number of modules affected will have
been increased.

 Tactic 4: Bind as late as possible

◦ A binding is simply an association between two things. Examples:
◦ In an object-oriented programming language a variable name is bound to an object when
the object is assigned to the variable.
◦ A user interface uses a particular look and feel, so it is bound to it.
◦ In a service-oriented architecture a consumer finds a service from a registry and binds to
the service.
◦ A symbolic name such as www.open.ac.uk is bound to a numerical IP address
(137.108.198.32 at the time of writing, 2014).

44
 Section 4: Architecture, quality attributes and tactics

 Tactic 4: Bind as late as possible (Cont.)

◦ The longer we can delay any binding, the more flexible the system will be, because a
different choice remains available. Examples:

◦ Object-oriented programming languages typically allow the class of the object to which a
variable is bound to be decided at run-time, making it possible to vary behavior by
replacing an object of one class by one belonging to a different class.

◦ Instead of the code of a user interface binding it to a particular look and feel, the look and
feel can be decided at run-time from a configuration file, which can be changed as
required.

◦ In a service-oriented architecture a service may be replaced by a different one that meets

the same contract.

45
 Section 4: Architecture, quality attributes and tactics

4.5 Summary of section

 In this section you learnt about the six-part model for quality attribute scenarios.
 You saw that for a given quality attribute we can make a list of the general
possibilities for each part of the model and then, to express a particular
nonfunctional requirement, we choose an appropriate value for each part of the
scenario.
 Tactics for quality attributes are reusable solutions to the problem of achieving
particular qualities.
 You saw detailed examples of tactics for two example attributes – performance
and flexibility.
 You learnt that the main tactics for performance are managing demand, managing
system capacity, and matching resources to demand.
 The main tactics for flexibility are minimizing coupling, maximising cohesion,
keeping modules small, and delaying binding for as long as possible.

46
 Section 5: Putting it all together – enterprise architecture

 In this section we look at a widely used framework for creating and

running enterprise applications: Java Platform, Enterprise Edition (Java
EE), provided by Oracle.

 We outline how Java EE supports component-based development, giving

a simple example of an actual component.

 We demonstrate that the same functionality can easily be delivered as a

service as well, making it possible to interoperate with a wide variety of
clients.

 Finally we explore one possible architecture for the hotel system, showing
how a single enterprise application created within Java EE can contain
examples of many of the reusable styles and patterns

47
 Section 5: Putting it all together – enterprise architecture

5.1 Introducing Java EE

 Java EE is built on top of the Java language and consists of an

aggregation of many technologies that have been standardized over
the years and integrated into the Java EE platform, which continues to
evolve and grow as new technology standards emerge.

 Enterprise applications developed in Java EE can be distributed

across computer networks and, by and large, they work on all
operating systems.

 This is possible because of the separation between Java EE

applications, their infrastructure and the operating system: many
vendors provide Java EE infrastructures for various operating systems
and a Java EE application can be deployed in any of these
infrastructures.

48
 Section 5: Putting it all together – enterprise architecture

Java EE is made up of many technologies. These include:

 J2SE (Java 2 Platform, Standard Edition): The standard Java language, which
Java EE is built on top of.
 EJB (Enterprise JavaBeans): A technology for reusable server-side business
components, called enterprise beans.
The range of services Java EE provides for EJBs includes persistence,
distribution, security and transaction processing.
 Servlets, JSF (JavaServer Faces) and JSP (JavaServer Pages): Technologies
for constructing web pages and serving them to clients on demand.
 JPA (Java Persistence API): A technology for accessing relational databases.
 JMS (Java Message Service). A technology enabling software components to
communicate asynchronously with low coupling.
 JAX-WS (Java API for XML Web Services) and JAX-RS (Java API for RESTful
Web Services: Technologies for providing services that can be accessed over the
internet.
 JavaMail: A technology for sending email messages.

49
 Section 5: Putting it all together – enterprise architecture

 Support for component-based application in Java EE relies

on the notion of a container.

 A container is a special run-time environment provided by

Java EE that will provide components with supporting
services, such as the examples given in the list above for
EJBs.

 Because the container provides the supporting services,

developers can focus on the application logic and leave the
complexity of the infrastructure to the container.

50
 Section 5: Putting it all together – enterprise architecture

 Java EE provides several containers, shown in Figure 10.

51
 Section 5: Putting it all together – enterprise architecture

 The web container and the EJB container are normally part of the platform
supplied by an enterprise server, such as Oracle's GlassFish Server.

◦ A browser just means one of the common web browsers, such as Firefox or Chrome, that
can send requests to a web server and display the response.

 An application client is a component running on the user’s machine but

able to invoke operations directly on remote EJBs because it is running in
a special container that supports distributed access.

 In addition to the containers shown above, a browser with a Java plug-in

installed provides an applet container.

 An applet is a small Java program that is downloaded from a server and

executes in a container consisting of a Java plug-in installed in the client's
browser.

52
 Section 5: Putting it all together – enterprise architecture

5.2 An example EJB

 To illustrate EJBs we use a small example that converts between two
common units of land area – the acre and the hectare (ha).
 The EJB is to be accessible remotely, and for this we have to first define a
remote interface:
package converter;
import javax.ejb.Remote;
@Remote
public interface ConverterBeanRemote {
String convertLandArea(double area, String unit);
}

 The code in this section and the next is just so that you can get a feeling
for how components and services might be implemented in practice. You
are not expected to remember the details.

53
 Section 5: Putting it all together – enterprise architecture

5.3 An example service

 Service-oriented architecture and the implementation of services are huge

topics.

 Rather than being solely dependent on Java technology, it is possible to

implement the area converter as a RESTful web service.

 REST stands for REpresentational State Transfer.

 RESTful web services use a uniform interface consisting only of a set of

standard methods which are always the same for every service.

 These are the standard HTTP (hypertext transfer protocol) methods, used
by web browsers to communicate with web servers.

54
 Section 5: Putting it all together – enterprise architecture

The client side of REST

 Once deployed, the service can easily be accessed from a browser which
will send a GET request to the URL and display the response (Figure 11).

 The browser, unlike the EJB client, is not aware of the Java technology used at
the server end. It simply sends a request and receives a response, using standard
protocols.

55
 Section 5: Putting it all together – enterprise architecture

5.4 An architecture for the hotel system

 In this subsection we explore what a Java EE architecture for the hotel
system could look like.

 Example:

 Read the following information about the hotel system and then sketch on
paper a possible way of building it as a Java EE application, showing
what components would be involved, what containers they would run in
and what the communication is.

◦ The hotel system will require three types of client: web clients connecting via the internet,
desktop applications installed in hotels, and mobile clients using tablet and phone apps
that connect to RESTful web services. Part of the system must deal with the core
business processes, such as reservations, room lettings, billing and so on. The system
will need to maintain persistent data about customers and hotels.

56
 Section 5: Putting it all together – enterprise architecture

Solution

 Note: Please practice the remaining SAQs in this section

57
 Section 5: Putting it all together – enterprise architecture

5.5 Summary of section

 In this section we introduced you to Java Platform, Enterprise Edition, a

framework for constructing large-scale systems.

 You learnt about the details of a small example of EJB to convert between
two different measures of land area.

 You also learnt that Java EE provides support for developing service
providers and saw how the same conversion example that you met in
component form can easily be reprogrammed as a RESTful web service.

 Finally we introduced a possible Java EE architecture for the hotel

system. This architecture uses a range of technologies, and contains
elements from several of the architectural styles you learnt about in Unit 9.

58
 Unit Summary

On completion of this unit you should be able to:

 discuss characteristics of software components and model simple

components

 explain how objects can function as components

 define service-oriented architecture and explain some of its advantages

 write and apply simple quality attribute scenarios

 explain the role of tactics in meeting quality requirements and discuss

their application in simple cases.

59