Enterprise Application Integration

Enterprise Application
Integration
 Ruh, Maginnis, Brown (2001) text
 Vendors
 Internet Resources
 Web Services
 EAI Journal online and print
Integration
 Packaged applications
 Legacy applications
 Data from variety of sources
 Stovepipe apps
Integration
 C 1 Business Drivers
 C 2 Types of Integration
 C 3 Building Blocks
 C 4 MOM
 C 5 Object arch
 C 6 Transaction arch
Integration
 Stats
 30-60 % IT resources on integration
 35 % of budgets
 85 % IT projects not completed
 58 % large projects over budget
 63 % projects off schedule
 58 % report success below 50%
Integration
 Select
 Architect
 Apply
 Common Building Blocks

Integration
 Messaging Architecture
 IBM MQ Series
 Object Architectures
 EJB
 Transaction Architecture
 BEA Tuxedo
Integration
 Introductory text
 Look at concepts
 Then vendor applications
 Web Services later
Integration
 Technology is always changing
 Concepts
 Frameworks
 Application in an organization
Integration
 Key Facts p.1
 Definition p.2
 Enterprise Application Integration is the
creation of business solutions by
combining applications using common
middleware.
Integration
 Middleware is application-independent
software that provides services that
mediate between applications.
 Multiple types
Integration
 Goals
 Quick, easy, cheap
 Improved relationships
 Supply chains
 Mergers and acquisitions
 BPI
 Speed
Integration
 360 view of relationships p.4
 Stovepipe applications definition p.5
 Examples and issues
 Supply-chain
 Examples and issues
Integration
 XML p.6
 BPI
 Speed p.7
 Legacy applications
 Packaged solutions COTS
Integration
 Internet p. 8-11
 Dot-bomb
 B2B, B2C
 Intranets
 Extranets
Integration
 Barriers to EAI
 Custom API, application programming
interfaces
 Vendors
 Skills – EAI
 Security
Integration
 Types of integration
 Chapter 2
 Key facts
 Integration model defines how
applications will be integrated by
defining the nature of and mechanisms
for integration
Integration
 Presentation
 Data
 Functional
 Pages 19-21
Integration
 Presentation integration model allows
the integration of new software through
the existing presentations of the legacy
software. This is typically used to
create a new user interface but may be
used to integrate with other
applications.
Integration
 Data integration model allows the
integration of software through access
to the data that is created, managed
and stored by the software typically for
the purposes of reusing or
synchronizing data across applications.
Integration
 Functional integration model allows the
integration of software for the purpose
of invoking existing functionality from
other new or existing applications. The
integration is done through interfaces to
the software.
Integration
 Coupling
 White box integration
 Black box integration
Integration
 Presentation integration model p.22
 When to use it
 Green screen
 One look
 Only choice
 Examples
Integration
 Pros and Cons
 Skill level
 Speed
 Less complex
 Performance low
 Most limiting
Integration
 Data integration p. 24
 Batch file transfer
 Open database connectivity
 Data access middleware
 Data transformation
Integration
 When to use it
 Analysis of data
 Data warehouse
 Different vendors
 Synchronize
 EIS
Integration
 Pros and cons
 Flexible
 Reused
 Lack of functionality
 Simple access to data
 No logic access
Integration
 Functional integration model p.29
 Business logic
 RPC’s
 Distributed processing middleware
Integration
 Distributed processing middleware
 MOM
 DOT
 TPM
Integration
 MOM
 Passing messages
 IBM MQ series
 Talarian Smart Sockets
Integration
 Distributed object technology
 OMG CORBA
 Microsoft COM+
 Sun’s J2EE
Integration
 TPM
 Transactions
 BEA Tuxedo
Integration
 Breadth of functional integration
 Data consistency
 Multistep process
 Plug and play components
Integration
 Data consistency integration is
integration through the code of an
application where the purpose is to
access or update data. The integration
facilitates the communication of data
and actions.
Integration
 Multistep process integration, also
known as straight-through processing,
is the integration of applications where
there is not only communications of
requests but also the coordination and
management of these requests across
applications. The integration facilitates
communication of the request and
manages the flow and sequencing.
Integration
 Plug and play component integration is
the integration of applications where a
well-defined interface exists that allows
a component to be easily connected
with other components without
modification. The integration facilitates
the communication of requests and
handles all of the interface definition
and management.
Integration
 Table 2.1
Integration
 When to use it
 Difficulty
 Performance
 Future reuse
 Examples
Integration
 Pros and cons
 Robust
 Flexible
 Reuse
 Complex
 Difficult software
 May not be possible
Integration
 Chapter 3 p.39
 Key facts
Integration
 For EAI solutions need
 Methodology
 Technology
Integration
 Communication model
 2 choices
 Synchronous – wait until reply is received
 Asynchronous – continue processing
Integration
 Receiver is software that receives a
request from a sender.
 Request is a formatted set of actions

and data sent from a sending piece of
software to a receiving set of software
Integration
 Reply is a formatted set of data and
possibly associated actions that are sent
as a result of a request
 Sender is software that sends a request

to another software component
Integration
 Synchronous communication occurs
when the communication between a
sender and receiver is accomplished in
a coordinated manner. This requires
the sender and receiver to operate
dependent on the processing of
request.
Integration
 Interactive systems require synchronous
communication.
 Examples
Integration
 Three types of synchronous
communication
 Request/Reply
 One-Way
 Synchronous polling
Integration
 Request/reply communication is a form
of synchronous communication where a
sender makes a request of a receiver
and waits for a reply before continuing
to process.
 Page 42
Integration
 One-way communication is a form of
synchronous communication where a
sender makes a request from a receiver
and waits for a reply that acknowledges
receipt of the request.
 Page 43
Integration
 Synchronous polling communication is a form
of synchronous communication where a
sender communicates a request to a receiver
but instead of blocking continues processing.
At intervals defined by the developer, the
sender checks to see if a reply has been sent.
When it detects a reply it processes it and
stops any further polling for a reply.
Integration
 Asynchronous communication occurs when
the communication between a sender and
receiver is accomplished in a manner that
allows each of them to operate independently
of the other. The receiver of the request is
under no obligation to handle the
communications or respond to the sender.
The sender continues to operate once the
request is sent without regard to how the
receiver handles the communication.
Integration
 Three popular types of asynchronous
communications
 Message passing
 Publish/Subscribe
 Broadcast
Integration
 Message passing is a form of asynchronous
communication where a request is sent from
a sender to a receiver. When the sender has
made the request, it essentially forgets it has
been sent and continues processing. The
request is delivered to the receiver and is
processed.
 Page 46
Integration
 Publish/subscribe is a form of
asynchronous communication where a
request is sent by the sender and the
receiver is determined by a declaration
of interest by the receiver in the
request.
 Page 47
Integration
 Broadcast is a form of asynchronous
communication in which a request is
sent to all participants, the receivers, of
a network. Each participant determines
whether the request is of interest by
examining the content.
 Page 48
Integration
 Methods of integration
 Messaging
 Interface definitions
Integration
 Messaging offers an easy to understand
approach for the construction, use, and
processing of the data.
 Interface based integration requires the

specification and implementation of a
well-defined interface that describes the
actions that an application can perform.
Integration
 A connector is logic that is programmed
into an application whose sole purpose
is to provide access to the presentation,
data, or functionality of the application
in a structured manner. The connector
hides the complexity of translating and
communicating a message or an
invocation on an interface for use by
the application.
Integration
 Marshalling is the process of converting
sequences of parameters and complex
data structures into flat strings of bytes
that can be transmitted over a
communications link. Unmarshalling is
the process of correctly restoring the
original structures at the receiving end.
Integration
 Middleware is a type of software that
facilitates the communication of
requests between software components
through the use of defined interfaces or
messages. In addition, it provides the
runtime environment to manage the
requests between software
components.
Integration
 RPC
 Data access middleware
 Message oriented middleware
 Distributed object technology
 Transaction processing monitors
Integration
 Remote Procedure Calls is a type of
middleware that is based on the notion
of developing distributed applications
that integrate at the procedure level.
Integration
 Database access middleware is a type
of middleware that is based on the
notion of accessing distributed data
whether in files or databases.
Integration
 Open Database Connectivity
 OBDC
Integration
 Message oriented middleware is a type
of middleware that uses messages as
the method of integration; it provides
the ability to create, manipulate, store,
and communicate these messages.
Integration
 Distributed object technology is a type
of middleware that extends the
concepts of object-oriented technology
to distributed processing. Interfaces
are developed for applications that
make software look like objects.
Integration
 Transaction Processing monitors are a
type of middleware that preserves the
integrity of a transaction. They support
features such as rollback, failover, auto
restart, error logging, and replication to
eliminate single points of failure.
Integration
 VERY IMPORTANT
 Atomicity
 Consistency
 Isolation
 Durability
Integration
 Atomicity
 Transaction is all or nothing.
Integration
 Consistency
 Transactions always go from one consistent
state to another.
Integration
 Isolation
 Does not affect other data or processes
 Durability
 Recorded on nonvolatile medium
Integration
 Rollback capability
Integration
 Service
 Functional extension to basic
communication or middleware capability
Integration
 Chapter 4
 Messaging key facts
Integration
 Message queuing is a way to pass data
or make an invocation of a remote
function from a specific client to a
specific server, or from a server to a
server. p.63
Integration
 Request/reply, point to point
 The request message from a source and
the reply message from a target will
occur within a single transaction.
Integration
 FIFO
 Publish/subscribe messaging
 P.65
Integration
 Message translation is the ability to
convert data into a form that can be
transmitted in a message and the
subsequent ability to convert the data
back to its native format once the
message has reached its target.
Integration
 Queue management
 Synchronicity
 Response time
 Message content
 Message size
 Message priority
 Queue volume
 Queue timeouts
 Queue persistence
 Queue priority
Integration
 Persistence is the ability to temporarily
store the message until delivery.
 Transitory persistence is for the length
of time required for one or more
functions to complete, such as a
transaction.
Integration
 Figures on page 69
Integration
 Queue manager/router is a service that
can determine to which queue a
message should be routed based on
message content, queue availability, or
preset rules.
Integration
 Message queuing
 Data transport
 Data integration
 Application Integration
 Enterprise Integration
 Vendors
Integration
 MegaMoney Bancorp
 Goals
Integration
 Chapter 5 Goals
 P. 83
Integration
 Three types of distributed object
architecture discussed
 DCOM/COM+
 CORBA
 EJB
Integration
 Charts on p. 85, 86
 OMA
 The object management architecture is
the specification for CORBA (Common
Object Request Broker Architecture)
software in the form of services and
facilities for business domains.
Integration
 ORB
 The object request broker (ORB) is the
mechanism for transparently
communicating client requests to target
object implementations.
Integration
 Services layers
 Application objects
 Domain Facilities
 CORBA Facilities
 CORBA Services
 Object Request Broker
Integration
 CORBA is a distributed object
technology that is platform independent
and enables remote object creation and
remote object method invocation. It is
based on the use of an object request
broker with published CORBA services.
Integration
 OMG (Object Management Group) is
the focal organization for the definition
and adherence to the OMA and CORBA.
http://www.omg.org
Integration
 ORB is a distributable component that
can communicate with other ORBS to
provide distributed object lifecycle
services across multiple platforms.
Integration
 ORB provides
 Operating system transparency
 Object life cycle services
 Remote object method calls
Integration
 CORBA Services offer a set of
distributed object functionality that is
required to be available for an
application developer to build the
distributed application on top of, makes
CORBA easier to use for distributed
application development, and removes
the need to program at the
communications level of the ORB.
Integration
 CORBA Facilities are application level
services that are intended to be used as
distributable components of a
distributed application.
 Examples p.91
Integration
 CORBA domains are line-of-business
oriented and issue specifications for use
within their specific business domain.
 Example
Integration
 CORBA 3 features
 Firewall spec
 Interoperable Name Service
Specification
 Asynchronous messaging and quality of
service control
 Minimum fault tolerance and real-time
CORBA
Integration
 Fault tolerance is the ability for errors
to occur without crashing the system,
ensuring a stable, known system state.
Integration
 CORBA components p.93-4
 Drawbacks
 Stability
 Services
Integration
 IBM Component Broker is a CORBA
implementation and is an enterprise
solution for distributed object
computing that includes an operational
environment and tool set and is
available as a part of IBM Enterprise
Edition of WebSphere Application
Server.
Integration
 Thin clients
 P.98
Integration
 Microsoft Windows DNA
 Does not use CORBA
 Uses COM+ model
Integration
 Sun
 J2EE
 EJB environment
Integration
 MegaMoney Bancorp
Integration
 Transaction architecture
 Key facts p.107
Integration
 Transaction processing monitors ensure
the integrity of business processes by
providing atomicity, consistency,
isolation, and durability of transactions.
Integration
 VERY IMPORTANT
 Atomicity
 Conistency
 Isolation
 Durability
Integration
 Atomicity
 Transaction is all or nothing.
Integration
 Consistency
 Transactions always go from one consistent
state to another.
Integration
 Isolation
 Does not affect other data or processes
 Durability
 Recorded on nonvolatile medium
Integration
 P.109 transactions
 A transaction is the implementation of
one or more business functions based
on associated business rules, where the
transaction is completed only when all
of the required business functions are
completed as specified by the business
rules.
Integration
 Rollback capability
Integration
 Mainframe Transaction processing
monitors
 CICS
 IMS
Integration
 Distributed Transaction Processing
Monitors
 BEA Tuxedo
 Transarc Encina
Integration
 Distributed Transaction Processing
standard is an open industry standard
that specifies how transactions are to
be coordinated. The DTP is widely
supported by databases and TPM’s.
Integration
 Four participants
 Applications
 Resource Managers
 Transaction Managers
 Communication resource managers
Integration
 Two-phase commit is the mechanism
used by the DTP to ensure the integrity
of distributed transactions.
Integration
 Transaction monitor services
 Programming models
 Synchronous request/response
 Asynchronous request/response
 Conversational
 Events
Integration
 Message queuing
 Security
 Conversion and translation
 Server management
 Administration
 Gateways
Integration
 Object transaction monitor
 An object transaction monitor is a product
that provides distributed objects with
transactional integrity.
Integration
 Object transaction service is the CORBA
standard for distributed object
transactions. OTS defines how the
Open Group model can be applied to
CORBA objects.
Integration
 Example on p. 121
Integration
 A nested transaction is a transaction
within a transaction.
Integration
 EJB model is strongly transactional.
Integration
 Strengths and weaknesses
 Integrity
 Coordination
 Services
 Too tightly coupled
 Too time consuming
 Legacy problems
Integration
 Alternatives
 Messaging – completed or certain to be
completed
 Must be transactional
 Integrity will not be compromised by
deferring
 Soft rollback
Integration
 MegaMoney example

Enterprise Application Integration

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Enterprise Application Integration

Загружено:

Авторское право:

Доступные форматы

Enterprise Application

 Common Building Blocks

 Request is a formatted set of actions

 Sender is software that sends a request

 Interface based integration requires the

Вам также может понравиться