Scribd
Upload
294 views24 pages

B2B Integration - Architecture

This document provides an overview of the architecture for a B2B integration system. It describes a 4-layer architecture with components in each layer. The layers include a user interface layer, integration logic layer, connectivity layer, and persistence layer. Components have interfaces to provide operations to other components. The architecture uses a state-based approach where integration instances and types have lifecycles and data is persisted consistently across components. Coordination is needed for requests from the user interface and processing incoming messages to ensure proper invocation order between components. An example integration scenario is provided to illustrate the architecture.

Uploaded by

Khurram Ch
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
294 views24 pages

B2B Integration - Architecture

This document provides an overview of the architecture for a B2B integration system. It describes a 4-layer architecture with components in each layer. The layers include a user interface layer, integration logic layer, connectivity layer, and persistence layer. Components have interfaces to provide operations to other components. The architecture uses a state-based approach where integration instances and types have lifecycles and data is persisted consistently across components. Coordination is needed for requests from the user interface and processing incoming messages to ensure proper invocation order between components. An example integration scenario is provided to illustrate the architecture.

Uploaded by

Khurram Ch
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 24

B2B Integration

Architecture Overview

Kluckner Thomas
Haider Florian
Overview Part 1

 Introduction

 Invocation Pattern

 Component Structure
 Component Interface
 Component Parts

B2B Integration – Architecture Overview


Overview Part 2

 State – Based Architecture

 Coordinated Architecture
 User Interface Invocations
 Invocations Processing Incoming Events

 Integration Example

B2B Integration – Architecture Overview


Introduction Part 1

 Architectural principles

 Overall description of the system


behaviour

B2B Integration – Architecture Overview


Introduction Part 2

 4-Layer Architecture
 Each Layer: Several
Components

 Interaction is top down

 No Layer skipped!

 Each Layer calls


underlying layer to get
his functionality
B2B Integration – Architecture Overview
Invocation Pattern Part 1

 may cause problems


(e.g.: Integration L.
Layer calls for object
instance)

 solution: auxiliary
components ( provide
certain necessary
operations)

B2B Integration – Architecture Overview


Invocation Pattern Part 2

 Why have this encapsulation with aux.


Components? In the implementation layers can be
skipped anyway...

 Main reason: filtering of operations


 clear architecture description
 easier to construct

 In implementation: additional requirements,


e.g. performance and scalability

B2B Integration – Architecture Overview


Component Structure
Interface Part 1

 Interface  operations with according


parameters

 Each component has interfaces to


provide to invoking components
 „public export interface“
 „layer private component interface“

B2B Integration – Architecture Overview


Component Structure
Interface Part 2

Public export interface


 visible for both
components in same layer
and those from layer
above

Layer private component


interface
 visible only for
components in same layer

B2B Integration – Architecture Overview


Component Structure
Interface Part 3

Example: Interface for creating interface


process type

create_interface_process_type( IN type_name:
string, OUT identifier: integer )

OUT  each parameter must be defined either IN or OUT


identifier  parameter name
integer  data type

B2B Integration – Architecture Overview


Component Structure
Parts Part 1

 Components responsible for modelling


data  must deal with type and instance
data simultaneously

 E.g.: process management component


(integration logic layer)

 manages process types and process


instances of those types

B2B Integration – Architecture Overview


Component Structure
Parts Part 2

Alternative Solutions:
 Separation of operations on type and

instance data in component interfaces


+ clear structure
+ clear invocation behaviour

 2 components instead of 1
(one for type, one for instance data)
+ clearer separations
- functionality applied to both
can‘t be easily shared

B2B Integration – Architecture Overview


State-Based Architecture
Part 1

 Presented architecture  state-based

 Integration instances and types have


life-cycle model and are in certain
state

 Persistence layer holds consistent and


complete set of type and instance data
at all points in time

 Data can be shared between several


components
B2B Integration – Architecture Overview
State-Based Architecture
Part 2

Alternative Solution:
Queue-based architecture

 Components don‘t share common data


model
 Data is passed between themselves in
form of queue elements (messages)

B2B Integration – Architecture Overview


State-Based Architecture
Part 3

Problems:
 Data only in queue (element must contain type
and instance data)

 No common state available (data can‘t be shared


through shared persistent state)

 Main problem: 2 components work on same data


(each one has copy of data)  one comp.
changes data, the other one can‘t notice the
change
 lack of consistence!!

B2B Integration – Architecture Overview


Coordinated Architecture
 Requests from user interface,
incoming messages

 Specific invocation of several


components

 Coordintation required

B2B Integration – Architecture Overview


Coordinated Architecture
User Interface Invocations

User Interface
Layer UI Comp. A UI Comp. B ...

Integration
Logic Layer IL Comp. A ... ...

Connectivity
Layer CL Comp. A ...
Persistence
Layer PL Comp. A ...

 Hierarchical Invocation Pattern


Important: Correct Invocation Order
B2B Integration – Architecture Overview
Coordinated Architecture
Invocations Processing Incoming Events
Part 1

Incoming
Message

Transport Security Packaging


Component Component ...
Component
Receives Decrypts and Unpacks wire message
Message accepts Message packaging

 Hierarchical Invocation Pattern


originated at Transport Component

B2B Integration – Architecture Overview


Coordinated Architecture
Invocations Processing Incoming Events
Part 2

Problems:
 Invocation hierarchy starts at connectivity
layer  impossible to call processing
components from integration logic layer

 Transport component needs information about


security component, which has to know about
packaging component...
(components should focus on their
functionality)

B2B Integration – Architecture Overview


Coordinated Architecture
Invocations Processing Incoming Events
Part 3

Solution:
Connectivity and Integration Logic Layer
have a „Coordinator component“

 Coordinates invocation within one layer


 Correct invocation and execution

B2B Integration – Architecture Overview


Coordinated Architecture
Invocations Processing Incoming Events
Part 4

Coordinator
Incoming Component
Message

Transport Security Packaging


Component Component
...
Component
Receives Decrypts and Unpacks wire message
Message accepts Message packaging

 Coordinator Component takes over


invocation control when notified

B2B Integration – Architecture Overview


Coordinated Architecture
Invocations Processing Incoming Events
Part 5

Advantages:
+ ensures components focus on their functionality
+ component don‘t need to know each other
+ enforces necessary invocations sequences

 Indirect Communication between connectivity


and integration logic layer:
 Connectivity layer processes incoming message and
stores it in persistence layer
 Coordinator component of integration logic
layer is notified and periodically checks for
messages

B2B Integration – Architecture Overview


Integration Example Part 1

 one-way notification
 trading partners A,B, Customer C
 A: obliged to ship a product
 A=>B: sends shipment notification
 B: receives notification
 B=>C: notify the customer by
email

B2B Integration – Architecture Overview


Integration Example Part 2

 incoming notification
is transformed,
translated
 business process splits
the business event
 business process sends
out copies
 different process
bindings and interface
processes

B2B Integration – Architecture Overview

You might also like