pdf viewer in c# code project : Copy and paste image from pdf software SDK cloud windows wpf winforms class software-architecture-practice140-part1372

[ Team LiB ]
Chapter 17. The Luther Architecture: A Case Study in Mobile
Applications Using J2EE
with Tanya Bass, James Beck, Kelly Dolan, Cuiwei Li, Andreas Löhr, Richard Martin, William Ross,
Tobias Weishäupl, and Gregory Zelesnik
Note:
All of this chapter's contributors work for Inmedius Corporation in Pittsburgh.
God is in the details.
—Ludwig Mies van der Rohe
Workers involved in the maintenance or operation of large vehicles (such as tanks and aircraft) or
portions of the industrial infrastructure (such as bridges and oil rigs) have great difficulty using computers
to support their tasks. Because the object being maintained or operated is large, work on it must be in
situ, outdoors or in special structures, neither of which is conducive to desktop computing. In particular, a
computer solution usually involves a wireless infrastructure and either a handheld or a hands-free
computing device.
Inmedius is a company that was established in 1995 as an outgrowth of Carnegie Mellon University's
Wearable Project (see the sidebar History of Wearable Computing
) to provide support for front-line
maintenance and operation workers. Initially producing one-of-a-kind solutions for its customers, as the
company grew it realized the necessity for general solutions that could be quickly tailored to a customer's
needs.
The front-line worker does not work alone but requires a great deal of back-office support. Problem
reports must be collected and work must be scheduled to enable repairs to be made, replacement parts
must be taken from inventory and re-ordered, and maintenance records must be analyzed. All of this
work-flow management requires integrating the front-line worker with the back-office worker who has
access to a desktop computer.
The Luther architecture was designed to provide a general framework within which Inmedius could
provide customized solutions for the maintenance problems of its customers. It is based on the Java 2
Enterprise Edition (J2EE) architecture, so becomes an application of the general J2EE/EJB framework
(discussed in Chapter 16
) to an environment where the end user is connected over a wireless network
and has a device with limited input/output capabilities, limited computational capabilities, or both.
History of Wearable Computing
Arguably, the first wearable computer was the wristwatch. It was invented around 1900 and at
first was unable to compete with the pocket watch. Why would someone wear a watch on his
wrist when his existing pocket watch kept good time and could be accessed quite freely?
However, during World War I, the British Army issued wristwatches to its troops so that they
could synchronize attacks while keeping their hands free for weapons. Suddenly, it became
fashionable in Britain to show support for the "boys in the trenches" by wearing wristwatches.
Now, of course, you rarely see a pocket watch.
By the early 1990s, technology had begun to support the wearing of digital, full-function
computing devices. One organization investigating the use of these devices was the Wearable
Group of Carnegie Mellon University headed by Dan Siewiorek. They viewed a wearable
computer as a tool to support workplace functions, with the workplace epitomized by locales
where aircraft and other large vehicles were maintained—out of doors or within large buildings
such as hangars or railroad roundhouses.
The focus on use in a workplace meant that ease of use and design sophistication were
primary. The Wearable group conducted experiments with computers designed and
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
400 / 463
Copy and paste image from pdf - copy, paste, cut PDF images in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Detailed tutorial for copying, pasting, and cutting image in PDF page using C# class code
how to cut a picture from a pdf document; how to copy and paste a pdf image
Copy and paste image from pdf - VB.NET PDF copy, paste image library: copy, paste, cut PDF images in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
VB.NET Tutorial for How to Cut or Copy an Image from One Page and Paste to Another
how to copy pictures from pdf to word; copy image from pdf to pdf
constructed by students in actual workplaces. The success of these experiments created the
demand that Inmedius was organized to exploit.
A second group, operating at the same time and centered at the Media Laboratory of the
Massachusetts Institute of Technology, styled themselves "borgs." They viewed the wearable
computer as a consumer product designed to change the lives of those who wore it. They
wore their computers all of the time and were interested in innovative uses of them and in
memory support applications. One example was using the conductivity of the skin as a
network medium and having two computers exchange business cards when their wearers
shook hands.
By the late 1990s, the two groups were collaborating to make wearable computers a viable
academic discipline. Various commercial companies had begun to offer computers and head-
mounted displays, and large commercial concerns had begun to show interest. Now, with the
increasing miniaturization of hardware and the increasing sophistication of software (as
evidenced by this chapter), wearable computing can only become more prevalent.
— LJB
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
401 / 463
C# PDF Page Extract Library: copy, paste, cut PDF pages in C#.net
C#.NET PDF Library - Copy and Paste PDF Pages in C#.NET. Easy to C#.NET Sample Code: Copy and Paste PDF Pages Using C#.NET. C# programming
paste jpg into pdf preview; cut and paste pdf images
C# PDF Image Extract Library: Select, copy, paste PDF images in C#
How to C#: Extract Image from PDF Document. List<PDFImage> allImages = PDFImageHandler. ExtractImages(page); C#: Select An Image from PDF Page by Position.
cut picture pdf; how to copy pdf image to word
[ Team LiB ]
17.1 Relationship to the Architecture Business Cycle
Figure 17.1
shows the Architecture Business Cycle (ABC) as it pertains to Inmedius and the Luther
architecture. The quality goals of re-usability, performance, modifiability, flexibility of the end user device,
and interoperability with standard commercial infrastructures are driven, as always, by the business goals
of the customer and the end user.
Figure 17.1. The ABC as it pertains to Inmedius and Luther
INFLUENCES ON THE ARCHITECTURE
The next sections elaborate on the things that influence the Luther architecture.
End Users
Inmedius's business is providing computer support for front-line workers. Figure 17.2
shows such a
worker utilizing one of the hardware configurations supported by Luther applications. The worker is
performing an industrial process, the steps of which are displayed on the head-mounted display
apparatus that he is wearing. The computer is worn on the user's chest and uses a dial as its primary
input device. The process is described in a manual stored on the back-office computers, and the manual
pages are served to the worker as various steps of the process are completed, which can number more
than 500. The worker reports the results of portions of the process to the back office via the system. A
part may be replaced, for example, and the part number is reported so that the inventory can be adjusted
and any quality-control ramifications analyzed.
Figure 17.2. A field service worker using the Inmedius solution. Courtesy of Inmedius
Corporation.
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
402 / 463
VB.NET PDF Image Extract Library: Select, copy, paste PDF images
VB.NET PDF - Extract Image from PDF Document in VB.NET. Support PDF VB.NET : Select An Image from PDF Page by Position. Sample for
copy paste picture pdf; how to copy pictures from a pdf file
VB.NET PDF Page Extract Library: copy, paste, cut PDF pages in vb.
VB.NET DLLs: Extract, Copy and Paste PDF Page. Dim page As PDFPage = doc.GetPage(3) ' Select image by the point (50F, 100F).
copying image from pdf to powerpoint; extract images from pdf files without using copy and paste
The workers may need to use one or both hands to perform the process, so those hands are not
available for computer input. Further, workers may need to be mobile to carry out the tasks.
Different processes and customers may require different hardware configurations because requirements,
such as mobility and the number of hands available for computer input, can vary.
Developing Organization
If the Luther architecture can facilitate the development of complex enterprise solutions in a fraction of the
time they take to develop as standalone, "stovepipe" systems, Inmedius gains a significant competitive
advantage. To achieve this, the company must meet increasingly shorter time-to-market for enterprise
solutions. The development cycles for these solutions have to be in the low single-digit months for
Inmedius to remain competitive in its target markets.
Solution development must be performed quickly and frugally by a few tens of engineers. The quality of
the delivered solution must be high to ensure customer satisfaction. Also, the delivered software artifacts
must be easily modifiable so that corrections and enhancements require little effort by Inmedius and do
not compromise the integrity of the original solution's architecture.
Technology Environment
Luther has been influenced by developments in both software and hardware. As we discussed in Chapter
16
, J2EE provides enterprise solutions for commercial organizations. It was a good fit with the Luther
requirement to interoperate with back-office processes. J2EE also facilitates the packaging of domain-
specific application capabilities into re-usable components that can be combined in different ways.
In addition to software influences, emerging hardware technology has influenced Luther—specifically, in
the need to support small wireless computers with voice input capabilities and high-resolution, head-
mounted displays. On the other hand, differing environments may require different types of devices, each
with its own set of capabilities. This imposes a requirement that Luther be flexible with respect to the
types of user interfaces supported.
INFLUENCES ON THE ORGANIZATION
The influences of Luther on the organization are in the areas of organizational structure, software
developers' experience, and business approach.
Organizational Structure
Prior to Luther, Inmedius was a solution factory, with each solution developed as a stovepipe application
for a specific customer. Organizationally, the Solution Group was the largest engineering group in the
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
403 / 463
C# Create PDF from images Library to convert Jpeg, png images to
Best and professional C# image to PDF converter SDK for Visual Studio .NET. C#.NET Example: Convert One Image to PDF in Visual C# .NET Class.
how to copy pictures from a pdf to word; pasting image into pdf
VB.NET PDF insert image library: insert images into PDF in vb.net
VB.NET PDF - Add Image to PDF Page in VB.NET. Insert Image to PDF Page Using VB. Add necessary references: RasterEdge.Imaging.Basic.dll.
copy and paste image from pdf to pdf; how to copy and paste a pdf image into a word document
company. Luther's development created the need for a Products Group (containing a Component
Development Group) to engineer and maintain the domain-specific component capabilities the Solution
Group uses to create its solutions for customers. The Product Group is concerned with generalized
capabilities for markets, whereas the Solution Group is concerned with specific applications for individual
customers. This is an instance of a two-part organizational structure for software product lines, as
described in Chapter 14
and illustrated by CelsiusTech case study in Chapter 15
.
Software Developers' Experience
Prior to Luther, Inmedius was staffed with experienced and sophisticated software developers, who
nonetheless had a number of new criteria to satisfy in Luther's development:
Learning the Java programming language
Becoming Sun Java Programmer Certified
Learning the J2EE application architecture
Learning how to package capabilities as J2EE/EJBs
Learning how to create Java servlets and JavaServer Pages
Learning how to use the various J2EE services provided by J2EE implementations
Business Approach
The Luther architecture has had a dramatic effect on the way Inmedius does business. As we said in
Chapter 14
, single-system solutions require a large amount of resources, and this resource drain and the
stovepipe ,mentality associated with single system development inhibits global thinking. The move to a
product line based on Luther enabled Inmedius to begin thinking about product lines instead of focusing
on individual systems. Furthermore, as we saw with CelsiusTech, new markets became available to
Inmedius that could be seen as generalizations of existing markets, not only in a business sense but also
in a technical sense.
17.2 Requirements and Qualities
The Luther architecture was designed to meet two sets of complementary requirements. The first set
governs the applications to be built—namely, enterprise applications for field service workers. These
requirements are directly visible to customers, since failure to meet them results in applications that do
not perform according to expectations—for instance, an application that may work correctly but perform
poorly over a wireless network. The second set of requirements involves introducing a common
architecture across products. This reduces integration time, brings products to market faster, increases
product quality, eases introduction of new technologies, and brings consistency across products.
Overall, the requirements can be separated into six categories:
Wireless access
User interface
Device type
Existing procedures, business processes, and systems
Building applications
Distributed computing
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
404 / 463
C# PDF remove image library: remove, delete images from PDF in C#.
Text: Replace Text in PDF. Image: Insert Image to PDF. Image: Remove Image from PDF Page. Image: Copy, Paste, Cut Image in Page. Link: Edit URL. Bookmark: Edit
copy image from pdf to word; copy a picture from pdf
C# PDF Library SDK to view, edit, convert, process PDF file for C#
load PDF from other file formats; merge, append, and split PDF files; insert, delete, move, rotate, copy and paste PDF file page. C#.NET: Process PDF Image.
how to paste a picture in a pdf; preview paste image into pdf
Wireless Access
Field service workers must move about while performing their tasks. Furthermore, they must move about
in an environment rich in machines, hazards, and other people. In order to interact with back-office
systems, the devices used by workers must access remote servers and data sources without being
tethered by a landline to a local area network. Because of the variety of Inmedius customers, these
wireless networks may need to be of varying capacity and availability.
User Interface
Part of the Inmedius competitive advantage is its high-fidelity user interfaces, which allow a worker to
focus on the task at hand without being hindered by the interface or the access device. Different devices
have different screen footprints, and the Luther architecture must facilitate the display of meaningful
information on each of them. This does not mean constructing a single user interface and adapting it to all
device types. Instead, Luther must support the rapid construction of interfaces that filter, synthesize, and
fuse information in ways that are displayable on a particular device and useful to its user.
Variety of Devices
Field service workers use a variety of computing devices in the field. No one device will suffice for all field
applications, and each has limitations that must be addressed by the Luther architecture. Inmedius must
engineer performance-enhancing solutions to run on all of these devices, which include:
Personal data assistant (PDA) devices such as Palm Pilot, Handspring Visor, vTech Helio, IBM
WorkPad, and Apple's Newton and MessagePad 2000
Pocket PC devices such as Compaq iPAQ, Casio EM500, HP Jornada, and Phillips Nino
Handheld, pen-based tablets running Windows CE such as Fujitsu Stylistic and PenCentra and
Siemens SIMpad SL4
Handheld Windows CE PC devices with pen and keyboard such as Vadem Clio, HP Jornada 700
series, NEC MobilePro, Intermec 6651 Pen Tablet Computer, and Melard Sidearm
Wearable computing devices such as Xybernaut MA-IV, Via family of products, and Pittsburgh Digital
Greenhouse's Spot
Different classes of device have different memory footprints, processor speeds, and user input devices
that can radically affect a user's interaction style from one class to another. For example, a wearable
computer can bring the power of the desktop computer into the field, making client applications as
sophisticated there as they are in the office. Users in this case also have a plethora of input devices to
choose from, including keyboard, voice, pen, and custom devices.
On the other hand, the processor speeds, memory footprints, and available input devices for the PDA
class are severely limited, which means that user interactions that can be engineered for these devices
are also constrained. Still, PDAs are extremely important in the various contexts in which field service
workers perform their tasks. The Luther architecture must address the variability of the users' interaction
styles, which are limited by differences in hardware capability among the device classes.
Existing Procedures, Business Processes, and Systems
Field service workers are only one part of most enterprises. Information gathered by them must be stored
in the back office; instructions for them come, partially, from outside the field; and many applications
already support existing business processes.
To respond to these needs, the Luther architecture must intergrate its functions with a worker's existing
procedures and processes, enable applications to be hosted on servers and databases from many
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
405 / 463
vendors, and simplify the integration of applications with legacy systems
Building Applications
Enabling faster construction of applications is one of the main motivations for Luther. There are a number
of aspects to this goal, including:
Encouraging software re-use and making it easier for applications to work together. This avoids
wasting valuable resources to "re-invent the wheel."
Enabling a build-first, buy-later strategy for enterprise functions (e.g., work flow).
Providing a stable platform for adoption of new features and emerging technologies that span
applications, such as location sensing, automatic detection and identification of nearby physical
objects and services, and advanced user interface features like synthetic interviewing.
Distributed Computing
The Luther architecture must provide enterprise application developers with a framework and
infrastructure that even out the differences in client device capabilities and provide application servers
with the following distributed application features.
Scalability.
The Luther server framework must facilitate scalability with no impact on performance.
That is, the addition of any number of domain-specific components over time must have no impact
on the performance of the application software, nor must it cause the re-engineering of client
applications. In addition, client applications must be easily reconfigurable to make use of added
capability. The framework must also support the ability of applications to discover new capability and
to dynamically reconfigure themselves to make use of it.
Load balancing.
The Luther architecture must support load balancing in a distributed environment.
Most of the computation in its applications will be performed on the server side, with the results sent
to the client. As more and more clients access the capability from a given server, the application
server infrastructure will have to detect heavy loads on a given server and offload processing to
application server components located on different server nodes within the enterprise. Similarly, the
enterprise environment application must be able to detect a node failure and shift to another
application server in the enterprise to continue execution. In both cases, load balancing must be
transparent to the user, and in the first case it must also be transparent to the client application.
Location independence.
To support load balancing, domain-specific application capability must be
distributed, and the Luther architecture must support this. To be able to change locations
dynamically, applications must be location independent.
Portability.
Enterprise application environments invariably comprise a set of heterogeneous server
hardware platforms. The Luther architecture framework will have to allow the software to run on
myriad platforms in order for enterprise applications to work.
[ Team LiB ]
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
406 / 463
[ Team LiB ]
17.3 Architectural Solution
The main architectural decision made in response to requirements was that Luther would be constructed
on top of J2EE, which has the following advantages:
It is commercially available from a variety of vendors. Components, such as work-flow management,
that may be useful in Luther are being widely developed.
HTTP becomes the basis of communication because it is layered on top of the TCP/IP protocol,
which in turn is supported by a variety of commercial wireless standards, such as the IEEE 802.11b.
Any Web-based client can be made mobile given the appropriate wireless LAN infrastructure. Most
of the devices that must be supported by Luther can support HTTP.
It separates the user interface and allows the 
user experience
paradigm to be implemented. This
paradigm proposes that the computer and its application be another, noninvasive, tool for the field
service worker. It must be a natural extension of the way that tasks are performed, yet provide
performance-enhancing benefits for both the field service worker and the organization.
The paradigm goes on to say that multiple views of an enterprise application should be developed,
each for a particular field service worker's role. A view is tailored to that role to enhance performance
and job satisfaction, and filters, fuses, synthesizes, and displays the appropriate information for it.
The view includes the use of role-appropriate input devices.
For example, if a keyboard is not appropriate, perhaps voice input can be used. If the environment is
too noisy, perhaps a custom input device like a 
dial
is used, which a user can turn (the dial is
mounted on the user's uniform as shown in Figure 17.2
) to navigate through links, buttons, radio
buttons, and other similar UI widgets in the client application to make them hot. In the middle of the
device, the user can tap an "enter" key to select the link, click the button, and so forth. This device
can be used in the most rugged environments, for example, even when a worker is wearing thick
gloves.
"Separating the user interface" is a tactic we saw for usability in Chapter 5
. In Luther it brings the
flexibility to change the user interface and adapt it to different devices and needs as well, which is a
kind of modifiability. Again we see that some tactics apply to achieving more than one kind of quality
attribute.
It supports the separation and abstraction of data sources. The user experiences require the
filtering, fusion, synthesis, and display of data that comes from multiple, disparate data sources.
Some of these data sources are database management systems, others are legacy applications built
on enterprise resource planning systems that encapsulate corporate data. Inmedius realized that by
abstracting and separating data sources from the applications that use them and by providing them
with well-defined, standard interfaces, the applications remain true to their defined abstractions and
thus are re-usable. Additionally, some interfaces are industry standards, such as JDBC/ODBC,
which allow the data sources themselves to be treated as abstract components that can be swapped
in and out of the enterprise application at will.
Figure 17.3
shows how a Luther application interacts with its environment. (It does not show the J2EE
elements; we will discuss the mapping of the application to J2EE shortly.) First, note the (n:1:m)
relationship among user interfaces, applications, and what Inmedius calls "components," that is, building
blocks for application functionality. A Luther application is thin; much of its business logic is assembled
from existing components, and it is not tied to any specific user interface. Essentially, the application code
contains these three things:
Session state definition and management
Application-specific (i.e., nonreusable) business logic
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
407 / 463
Logic that delegates business requests to an appropriate sequence of component method
invocations
Figure 17.3. Deployment view of a Luther application
The application does not have a main method; it has an application programming interface (API), which
represents the features and functions available from the application to its user interfaces. The user
interface is independent of the application. It may expose any subset of features appropriate for the target
interface device. For instance, if a user interface is created for a device with a microphone and speaker
but no display, it does not expose features of the application that require graphics.
Now we turn to an in-depth discussion of the three main elements shown in Figure 17.3
: the user
interface (UI), the application, and the components.
USER INTERFACE
The strategy for developing user interfaces in the Luther architecture is as follows. First, a combination of
domain experts, cognitive psychologists, and graphic artists work with a client to understand the various
workers' tasks and roles, the work environments, and the necessary interface characteristics of the
desired access devices. Next, they craft the user experience based on these constraints, with the result
being a storyboard, screen shots, and a prototype. The point is that the result of the design process must
be a high-quality, high-fidelity user experience, as described before. This is essential, since the
application is meant to augment the user's existing work procedures and be a natural extension of the
work environment. Consequently, the task of developing the user experience is delegated to the people
best suited for it—domain experts who understand the task and the work environment; cognitive
psychologists who understand how people think, reason, and absorb information; and graphic artists who
are skilled at presenting information in an effective and appealing manner.
The next step is to take the output of the design process—the storyboard, screen shots, and prototype
—and quickly convert this to a working user interface on real devices. Here, the architecture must support
the integration of custom user experiences. Integration must be rapid, and it should enable creation of
common portions and re-use of software to the greatest extent possible, all the while preserving the
integrity and fidelity of the original user experience design.
Turning a user experience design into a working user interface is complicated by many factors. First, a
variety of client devices must be supported. This includes an assortment of mobile devices with varying
screen sizes, operating systems, and input devices. A user interface that performs well on a desktop PC
is severely limited by the smaller screen, less memory, and less functional support on a mobile device.
Some mobile devices, for example, have no keyboard or mouse support, rendering user interfaces that
require them useless. A second factor is the limitations introduced by technology. For instance, certain
types of user interaction or information display are cumbersome over HTTP and may lead to poor
performance.
In the end, there may be multiple client devices and user interfaces for any given application. The
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
408 / 463
software architecture must be flexible enough to deal with multiple clients that differ greatly from one
another. In Figures 17.4
and 17.5
, the two types of user interface implementation supported by Luther are
shown—namely, browser-based clients (Figure 17.4
) and custom, Web-based clients (Figure 17.5
).
Figure 17.6
refines the view given in Figure 17.3
and illustrates the structure of each type.
Figure 17.4. Browser interface for maintenance procedure
Figure 17.5. Custom Web-based user interface
Figure 17.6. User interface as a C&C view overlaid onto a deployment view
This PDF file was converted by Atop CHM to PDF Converter free version!  http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
409 / 463
Documents you may be interested
Documents you may be interested