SYSTEM INTEGRATION

& ARCHITECTURE 2
 MODULE 4

SYSTEM
INTEGRATION
• To understand the overall framework for system integration management as it
relates to the other project management knowledge areas and the system life
cycle
• To explain project plan execution, its relationship to project planning, the
factors related to successful results, and tools and techniques to assist in
project plan execution
SUBTOPIC 1
• The term “integration” refers to the software-development
activity in which you combine separate software
components into a single system.
• For small projects, integration might be shorter as compare
to larger projects that takes weeks or months
• Order of building classes or components affects the order
in which you can integrate them.
• Construction and integration of software should be done in a
correct order.
• When it is done in a wrong order, its harder to code, harder
to test and harder to debug
• None of it will work until all of it works, it can seem as though
it will never be finished
• Easier defect diagnosis
• Fewer defects
• Less scaffolding
• Shorter time to first working product
• Shorter overall development schedules
• Better customer relations
• Improved morale
• Improved chance of project completion
• More reliable schedule estimates
• More accurate status reporting
• Improved code quality
• Less documentation
• Service-oriented Architecture (SOA) is a way of
developing distributed system consisting a stand-alone
web services that may be executing on distributed
computers in different geographical regions
• What is distributed systems?
• A Distributed system is a collection of computers that
appears to be a single system
• It allows hardware and software resources to be shared
• Supports concurrency with multiple processors running
on different computers on the network
Figure 4.1 Distributed System
• SOA is an approach to create an architecture based
upon the use of services, where a service may carry
out some small functions such as producing data or
validating a customer
• A Web service is a computational or information
resource that may be used by another program, and it
allows a service provider to provide a service to an
application (service requestor) that wishes to use the
service.
Figure 4.2 Service Oriented Architecture
SERVICE-ORIENTED ARCHITECTURE IS AN
ARCHITECTURAL STYLE
• Derived from the client-server architectural style.
• Clients (service consumers or requesters) and servers
(service providers) connected by a service “bus”.
• Services defined using formal interfaces (contracts).

Slide 13 of 28
• Service bus supports point-to-point and messaging
styles of communication.
• Support for system qualities, e.g., security and
transaction management.
WEB SERVICES
• Services provided in a SOA deployed over the web.

Slide 14 of 28
 1960 - 1980 1990 - 2000 2010 – 2050

•Organization Focus •Process Focus •Distributed Functions

•Mainframe Centric •Client Server •Data Centric
•Internal Use •Partial Connectivity •Universal
•Unique Data •EDI File Transfer Interoperability
•Real-time Connectivity
• Quality of service, security and performance are specified.
• Software infrastructure is responsible for managing.
• Services are cataloged and discoverable.
• Data are cataloged and discoverable.
• Protocols use only industry standards.

Slide 16 of 28
• A Service is a reusable component.
• A Service changes business data from one state to another.
• A Service is the only way how data is accessed.
• If you can describe a component in Web Service Description
Language (WSDL), it is a Service.

Slide 17 of 28
 )
• The service interface is defined in a service description
expressed in WSDL.
The WSDL specification defines:
• What operations the service supports and the format of the
messages that are sent and received by the service.

Slide 18 of 28
• How the service is accessed - that is, the binding maps
the abstract interface onto a concrete set of protocols.
• Where the service is located. This is usually expressed
as a URI (Universal Resource Identifier).

Slide 19 of 28
WSDL service definition

Intro XML namespace declarations

Type declarations
Abstract interface Interface declarations
Message declarations

Concrete Binding declarations

implementation Endpoint declarations

Slide 20 of 28
• A WSDL documents describes a web service.
• It specifies the location of the service, and the methods of the service
using these major elements:
Element Description
<types> Defines the (XML Schema) data types used by the web service
<message> Defines the data elements for each operation
<portType> Describes the operations that can be performed and the messages
involved.

<binding> Defines the protocol and data format for each port type

Slide 21 of 28
Slide 22 of 28
Slide 23 of 28
• The <portType> element defines a web service, the operations that
can be performed, and the messages that are involved.
• The request-response type is the most common operation type, but
WSDL defines four types:
Type Definition
One-way The operation can receive a message but will not return a response
Request-response The operation can receive a request and will return a response
Solicit-response The operation can send a request and will wait for a response
Notification The operation can send a message but will not wait for a response
• One-way operation example:
• A request-response operation example:
• WSDL bindings defines the
message format and
protocol details for a web
service.
• A request-response
operation example:
• SOAP is an application communication protocol
• Is a format for sending and receiving messages
• Is platform independent
• Is based on XML

XML stands for eXtensible Markup Language much like

HTML. It was designed to store and transport data. Its self-
descriptive.
• Programming services using a standard programming
language or a workflow language.
• Services then have to be tested by creating input
messages and checking that the output messages
produced are as expected.

Slide 29 of 28
• Deployment involves publicizing the service using
UDDI and installing it on a web server. Current servers
provide support for service installation.

Slide 30 of 28
• is an XML-based standard for describing, publishing, and
finding web services
• stands for Universal Description, Discovery, and Integration
• Is specification for a distributed registry of web services

Slide 31 of 28
• Is a platform-independent, open framework
• Can communicate via SOAP, COBRA, Java RMI Protocol
• Uses WSDL to describe interfaces to web services
• Is seen with SOAP and WSDL as one of the three foundation
standards of web services
• Is an open industry initiative, enabling businesses to discover
each other and define how they interact over the Internet

Slide 32 of 28
SUBTOPIC 2
STANDARDS FOR WEB SERVICE
COMPOSITION
WEB SERVICE COMPOSITION
• Is the mechanism for combining and reusing existing Web
services to create new Web services.

The two web service compositions are:

1. Service choreography
2. Service orchestration

Slide 34 of 28
STANDARDS FOR WEB SERVICE
COMPOSITION
SERVICE ORCHESTRATION
• WS-BPEL is an XML-based language for workflow specification.
• WS-BPEL is an “orchestration” language.
• Service orchestration defines the sequence and conditions in
which one Web service invokes other Web services.
• Can be used to create a composite service out of other
services.

Slide 35 of 28
STANDARDS FOR WEB SERVICE
COMPOSITION
SERVICE CHOREOGRAPHY
• WS-CDL is an XML-based language for describing service
“choreography”.
• Choreography defines the allowable message exchanges between
services.
• It is targeted for composing interoperable, peer-to-peer collaborations
between any type of participant

Slide 36 of 28
ORCHESTRATION VS. CHOREOGRAPHY

ORCHESTRATION CHOREOGRAPHY
A Single Director In Defines Interaction.
Control.
ORCHESTRATION VS. CHOREOGRAPHY

Orchestration
within
services

Choreography
between
services

Slide 38 of 28
CHOREOGRAPHY PERSPECTIVE
ORCHESTRATION PERSPECTIVE
ORCHESTRATION AND CHOREOGRAPHY
 LEGACY SYSTEM SERVICES
• Legacy systems are old software systems
• Organizations rely on obsolete technology but are still
essential to the business
• Not cost effective to rewrite or replace these systems
• Many organizations would like to use them in conjunction
with more modern systems

Slide 43 of 28
 LEGACY SYSTEM SERVICES
• An important application of services is to provide access to
functionality embedded in legacy systems.
• Legacy systems offer extensive functionality and this can
reduce the cost of service implementation.
• External applications can access this functionality through the
service interfaces.

Slide 44 of 28
LEGACY SYSTEM SERVICES
• Some services provided:
1. A maintenance service. This includes operations to retrieve a
maintenance job according to its job number, priority, and
geographical location and upload details of maintenance.

Figure 4.2 Services providing access

to a legacy system
Slide 45 of 28
LEGACY SYSTEM SERVICES
• Some services provided:
2. A facilities service. This includes operations to add and delete
new equipment and to modify existing equipment information

Figure 4.2 Services providing access

to a legacy system
Slide 46 of 28
LEGACY SYSTEM SERVICES
• Some services provided:
3. A logging service. This includes operations to add new
request for service, delete maintenance requests, and query
status of outstanding requests

Figure 4.2 Services providing access

to a legacy system
Slide 47 of 28
1. Salvaging the legacy code
2. and
3. Making the code available as web service
• First, locate code worth reusing
• Here a domain expert is required
• Can be supported by automated reverse engineering
tools
• The function processes of business operations are
ways to identify variables or functions.
• There is a n:m relationship between code blocks and
business operations
• Next step is extract that code and reassemble it as a
separate module with its own interface.
• The by product of this code reengineering process is a
documentation of the existing business operation.
• With the use of data flow tree, it is possible for the user
to decide whether an existing operation, implemented
within a legacy system is worth reusing
• Once business operation has been located,
documented and found worthy of reuse, the next step
is to wrap it.
• Provide components extracted from legacy code with
WSDL interface.
Slide 52 of 28
• Third and last step is to link the web services to the
overlying business processes.
• Proxy component
• On the application server there is a scheduler that
receives incoming messages, determines the web
service and forwards the WSDL contents to a particular
service
 MAJOR PITFALLS WITH SYSTEM INTEGRATION
PITFALL DESCRIPTION
What is expected has The experience shows that the implemented
delay elements always do not arrive in the expected order
and the tests never proceed or result as foreseen;
therefore, the integration strategy should allow a
great flexibility.
Big-bang not The "big-bang" integration technique is not
appropriate appropriate for a fast detection of faults. It is thus
preferable to verify the interfaces progressively all
along the integration.
Integration plan too The preparation of the integration activities is
late planned too late in the project schedule, typically
when first implemented elements are delivered.

Slide 54 of 28
 PROVEN PRACTICES WITH SYSTEM INTEGRATION
PRACTICE DESCRIPTION
Start earlier development The development of assembly tools and verification and
of means validation tools can be as long as the system itself. It should be
started as early as possible as soon as the preliminary design is
nearly frozen.
Integration means seen as The development of integration means (assembly tools,
enabling systems verification, and validation tools) can be seen as enabling
systems, using system definition and system realization
processes . These projects can be led by the project of the
corresponding system-of-interest, but assigned to specific
system blocks, or can be subcontracted as separate projects.
Use coupling matrix A good practice consists in gradually integrating aggregates in
order to detect faults more easily. The use of the coupling
matrix applies for all strategies and especially for the bottom up
integration strategy.
Integration and design The integration responsible should be part of the design team.
teams

Slide 55 of 28
• Pressman, R. S. (2015). Software engineering: a practitioners approach. New York, NY: McGraw-Hill
• Douglass, B. P. (2016). Agile systems engineering. Waltham, MA: Morgan Kaufmann.
• Leach, R. J. (2016). Introduction to software engineering. Boca Raton: Chapman & Hall/CRC.
• Laplante, P. A. (2018). Requirements engineering for software and systems. Boca Raton: CRC Press.