Chapter 1. Introduction to Patterns for e-business 11
1.2.2 Selecting Application patterns
Once the Business pattern is identified, the next step is to define the high-level
logical components that make up the solution and how these components
interact. This is known as the Application pattern. A Business pattern will usually
have multiple possible Application patterns. An Application pattern may have
logical components that describe a presentation tier for interacting with users, an
application tier, and a back-end application tier.
Application patterns break the application down into the most basic conceptual
components, identifying the goal of the application. In our example, the
application falls into the Self-Service business pattern and the goal is to build a
simple application that allows users to access back-end information. The
Self-Service::Directly Integrated Single Channel application pattern shown in
Figure 1-4 fulfills this requirement.
Figure 1-4 Self-Service::Directly Integrated Single Channel
The Application pattern shown consists of a presentation tier that handles the
request/response to the user. The application tier represents the component that
handles access to the back-end applications and data. The multiple application
boxes on the right represent the back-end applications that contain the business
data. The type of communication is specified as synchronous (one request/one
response, then next request/response) or asynchronous (multiple requests and
responses intermixed).
Presentation
synchronous
Web
Application
synch/
asynch
Back-End
Application 1
Application node
containing new or
modified components
Application node containing
existing components with
no need for modification
or which cannot be changed
Read/Write data
Back-End
Application 2
12 Broker Interactions for Intra- and Inter-enterprise
Suppose that the situation is a little more complicated than that. Let's say that the
automobile policies and the homeowner policies are kept in two separate and
dissimilar databases. The user request would actually need data from multiple,
disparate back-end systems. In this case there is a need to break the request
down into multiple requests (decompose the request) to be sent to the two
different back-end databases, then to gather the information sent back from the
requests, and then put this information into the form of a response (recompose).
In this case the Self-Service::Decomposition application pattern shown in
Figure 1-5 would be more appropriate.
Figure 1-5 Self-Service::Decomposition
This Application pattern extends the idea of the application tier that accesses the
back-end data by adding decomposition and recomposition capabilities.
1.2.3 Review Runtime patterns
The Application pattern can be further refined with more explicit functions to be
performed. Each function is associated with a runtime node. In reality these
functions, or nodes, can exist on separate physical machines or can co-exist on
the same machine. In the Runtime pattern this is not relevant. The focus is on the
logical nodes required and their placement in the overall network structure.
As an example, let's assume that our customer has determined that their solution
fits into the Self-Service business pattern and that the Directly Integrated Single
Channel pattern is the most descriptive of the situation. The next step is to
determine the Runtime pattern that is most appropriate for their situation.
Presentation
synchronous
Decomp/
Recomp
synch/
asynch
Application node
containing new
or modified
components
Application node
containing existing
components with no need
for modification or which
cannot be changed
Read/
Write data
Transient data
- Work in progress
- Cached committed data
- Staged data (data replication
flow)
Back-End
Application 1
Back-End
Application 2
Chapter 1. Introduction to Patterns for e-business 13
They know that they will have users on the Internet accessing their business data
and will therefore require a measure of security. Security can be implemented at
various layers of the application, but the first line of defense is almost always one
or more firewalls that define who and what can cross the physical network
boundaries into their company network.
They also need to determine the functional nodes required to implement the
application and security measures. The Runtime pattern shown in Figure 1-6 is
one of their options.
Figure 1-6 Directly Integrated Single Channel application pattern::Runtime pattern
By overlaying the Application pattern on the Runtime pattern, you can see the
roles that each functional node will fulfill in the application. The presentation and
application tiers will be implemented with a Web application server, which
combines the functions of an HTTP server and an application server. It handles
both static and dynamic Web pages.
Internal Network
Demilitarized Zone
(DMZ)Outside World
Protocol
Firewall
Existing
Applications
and Data
Domain
Firewall
I
N
T
E
R
N
E
T
Public Key
Infrastructure
User
Web
Application
Server
Domain Name
Server
Directory and
Security
Services
Presentation Application
Application
Directly Integrated Single Channel application
Application
Existing
Applications
and Data
14 Broker Interactions for Intra- and Inter-enterprise
Application security is handled by the Web application server through the use of
a common central directory and security services node.
A characteristic that makes this Runtime pattern different from others is the
placement of the Web application server between the two firewalls. The Runtime
pattern shown in Figure 1-7 is a variation on this. It splits the Web application
server into two functional nodes by separating the HTTP server function from the
application server. The HTTP server (Web server redirector) serves static Web
pages and redirects other requests to the application server. It moves the
application server function behind the second firewall, adding further security.
Figure 1-7 Directly Integrated Single Channel application pattern::Runtime pattern:
Variation 1
These are just two examples of the possible Runtime patterns available. Each
Application pattern will have one or more Runtime patterns defined. These can
be modified to suit the customer’s needs. For example, the customer may want
to add a load-balancing function and multiple application servers.
Internal Network
Demilitarized Zone
(DMZ)
Outside World
Protocol
Firewall
Domain
Firewall
I
N
T
E
R
N
E
T
Public Key
Infrastructure
User
Web
Server
Redirector
Domain Name
Server
Presentation Application
Application
Directly Integrated Single Channel application
Application
Existing
Applications
and Data
Application
Server
Directory and
Security
Services
Existing
Applications
and Data
Chapter 1. Introduction to Patterns for e-business 15
1.2.4 Review Product mappings
The last step in defining the network structure for the application is to correlate
real products with one or more runtime nodes. The Patterns Web site shows
each Runtime pattern with products that have been tested in that capacity. The
Product mappings are oriented toward a particular platform, though more likely
the customer will have a variety of platforms involved in the network. In this case,
it is simply a matter of mix and match.
For example, the runtime variation in Figure 1-7 on page 14 could be
implemented using the product set depicted in Figure 1-8.
Figure 1-8 Directly Integrated Single Channel application pattern: Windows® 2000 Product mapping
Internal network
Demilitarized zone
O
u
t
s
i
d
e
w
o
r
l
d
Protocol
Firewall
Domain
Firewall
Web Server
Redirector
Windows 2000 + SP3
IBM WebSphere Application
Server V5.0 HTTP Plug-in
IBM HTTP Server 1.3.26
Directory and
Security
Services
LDAP
Application
Server
Windows 2000 + SP3
IBM SecureWay Directory V3.2.1
IBM HTTP Server 1.3.19.1
IBM GSKit 5.0.3
IBM DB2 UDB EE V7.2 + FP5
Database
Existing
Applications
and Data
Windows 2000 + SP3
IBM DB2 UDB ESE V8.1
JMS Option:
Windows 2000 + SP3
IBM WebSphere Application
Server V5.0
IBM WebSphere MQ 5.3
Message-driven bean application
Web Services Option:
Windows 2000 + SP3
IBM WebSphere Application
Server V5.0
IBM HTTP Server 1.3.26
IBM DB2 UDB ESE 8.1
Web service EJB application
JCA Option:
z/OS Release 1.3
IBM CICS Transaction Gateway
V5.0
IBM CICS Transaction Server
V2.2
CICS C-application
Windows 2000 + SP3
IBM WebSphere Application
Server V5.0
JMS Option add:
IBM WebSphere MQ 5.3
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.