FI PPP ArchB Contact: Andreas Metzger Paluno, U Duisburg-Essen FInest Architecture

FI PPP ArchB Contact: Andreas MetzgerPaluno, U [email protected]

FInest Architecture & Envisioned GE Usage

10.07.2012

mailto:[email protected]

Part I : FInest Conceptual Architecture (delivered Mo 12)

2

3

K&N joined the FInest platform

Kühne & Nagel, one of the worlds largest

logistic service providers, adopted the FInest

platform

AFKLM joined the FInest platform

Air France KLM Cargo joined the user

group for the FInest collaboration services

Paluno to offer eContracing App

Paluno (the Ruhr Institute for Software

Technology) offers a novel eContracting

app and gadget for the FInest platform…

SAP to deploy first FInest instance

SAP is to offer the FInest platform

services as part of their business by design

portfolio

T&L

Collaboration Space Status

DemandOffer

Planning

B2BFacebook

Vision

Context

Future Internet Core PlatformGeneric Enablers

T&L Stakeholders

FInest Transport and Logistics Collaboration Space Deployed in

the Cloud

Cloud Hosting

Interface to Network &

Devices

App/Service Delivery

Framework

Access to Internet of

Things

Business Collabora-

tion

eContract-ing

Proactive Event Moni-

toring

Transport (Re-)

Planning

Shipper Carrier (e.g., Airline) Forwarder Service Provider

Domain-specificCapabilities

Core

Mod

ules

5

Conceptual Architecture

• Architecture Model• Specification of interactions• Design of core modules

• Design Decisions• Security• Backend Integration• Data Interchange Model (GS1)

• Publications• R. Franklin et al. “Future Internet technology for the future of transport

and logistics (invited),” in ServiceWave 2011• Metzger, A. et al. “Predictive monitoring of heterogeneous service-

oriented business networks”, SRII Global Conference, 2012• R. Franklin et al. “Cloud Based Collaboration Platform for T&L Business

Networks, 6th Int’l Scientific Symposium on Logistics, 2012

Module Layer

E-Contracting Module(ECM)

Event Processing Module(EPM)

Business CollaborationModule (BCM)

Transport Planning Module(TPM)

Front EndLayer

Back EndLayer

List of matching contracts(long-/short-term)

Detected situation(e.g., SLA violation /timing violation/proof of delivery)

Information aboutactual bookingsand changes

(Re-

)pla

nnin

g tr

igge

r

Tran

spor

t exe

cutio

n pl

an

Situationsto monitor / rules(e.g., ETA of transport leg)

Smart ItemsSmart ItemsLegacy SystemsLegacy Systems3rd-party services3rd Party Services

Service-based System Integration

IoS and IoTMonitoring

Events(from IoT)

Multi-Channel Messaging (SMS, E-Mail, Social Networks)

Customizable Web Portal (using Gadgets á la iGoogle)

User-/Identity Mgt. & Access-Control

Notifications and request for actions Profiles of potential business partners

Events(from IoS& Legacy:EDI etc.)

Events about transport process

Secure Storage &Backup

Offers and demands

from spot-marketplaces

Final status & data of completed transport process

…Shipper Transport Planner Carrier (e.g., Airline)Forwarder

…

Transport bookings

Transportexecution data

Module Layer

Front EndLayer

Back EndLayer

Smart ItemsSmart ItemsLegacy SystemsLegacy Systems3rd-party services3rd Party Services



Multi-Channel Messaging (SMS, E-Mail, Social Networks)

Customizable Web Portal (using Gadgets á la iGoogle)

User-/Identity Mgt. & Access-Control


…

Shipper Transport Planner Carrier (e.g., Airline)Forwarder

…

Conceptual Architecture (1)

Business Collabora-

tion

eContract-ing

Proactive Event Moni-

toring

Transport (Re-)

Planning

Module Layer





List of matching contracts(long-/short-term)

Detected situation(e.g., SLA violation /timing violation/proof of delivery)

Information aboutactual bookingsand changes

(Re-

)pla

nnin

g tr

igge

r

Tran

spor

t exe

cutio

n pl

an


Events(from IoT)

Notifications and request for actions Profiles of potential business partners


Events about transport process

Offers and demands

from spot-marketplaces


Transport bookings

Transportexecution data

Conceptual Architecture (2)

Part II: Towards Technical Architecture (to be delivered by Mo24)

8

• STEP 1 (->| Mo18): From Conceptual to Technical Architecture• Definition of Modules/Components, Interface Definitions, Data Types

• Exploiting FI-WARE GEs (“integrating” into the FInest architecture)• Business-driven Architecture/Design Assessment ( WP1/WP2)

• STEP 2 (->| Mo24): From Technical Architecture to Technical Specification• Technical Components, Programmatic APIs (incl. Data Types)• Prototypical development

• Exploiting FI-WARE GEs (invoking Services / APIs in FI-WARE test bed instance)

Design Process

9

• Specification language (STEP 1)• TAM (using the technical concepts)• Decomposition and modules• Interfaces (abstracting from implementation technology)

• Operations• Data Types

• Technical API Definition (STEP 2)• RESTful (this is widely used throughout FI-WARE)

• Operations• Data Types

Modeling Techniques

10

Modeling Techniques (STEP1)

14

Use of GEs

GE Modeling (STEP 1)

15

Registry GE

RegisterEntry(key, entry)

DeregisterEntry(key)

GetRegistryEntry(key)

QueryRegistryEntry(filter)??

PUT/{DistinuguishedEntryName}

RESTFul API(Create & update entire entry)

POST/{DistinuguishedEntryName}(Create & update attribute of entry)

DELETE/{DistinuguishedEntryName}(Delete entire entry)

DELETE/{DistinuguishedEntryName}?attributes={AttributeNames}(Delete attribute of entry)

GET/{DistinuguishedEntryName}?filter={FilterExpression}&attributes={AttributeList}&scope={Scope}

“conceptual” interface definition

“technical” interface

Following the InstantMobility idea… (and somehow doing some redundant work)

Part III: Module Architecture & Envisioned Use of GEs

16

Cross-Cutting: Security

• Rely on FI-WARE GEs in “SPT” Chapter (incl. specific FInest feature requests)

• Three dimensions of SPT:• Front-end (access-based)• Back-end (access-based)• Artifact-based (business entity-based) in the BCM

17

Core Modules





Front End

Back End

List of matching contract s(long-/short-term)

Detected Situation(e.g., SLA violation /timing violation/proof of delivery)

Information aboutactual bookingsand booking changes

(Re-)planning trigger

Transport execution plan




Events(from IoT)

Messaging (SMS, E-Mail, …)Customizable Web Portal

(using Gadgets á la iGoogle)

User- and Identity Management & Access-

Control

Notifications and request for actions Profiles of potentialbusiness partners(“dating” ;-)


Events about transport

process


Retrieval of offers and demands

on spot-marketplaces


Artifact-centric security for BCOs

Access-based / Firewalls for Apps

Access-control to legacy systems

Secure Network Connections

Security Monitoring

GEs:

Cross-Cutting: Security

19

• Mandatory• Identity Management• Security Monitoring

• Optional GEs for Security• Anti-Malware• Secure Storage

• Additional required technologies• BYOD Security (security mechanisms for Bring-Your-Own-Device concept)• Document Right Management (Integrate access rights in documents

before exporting [e.g. Invoice, contract])• Network Security Solutions (Next Generation Firewall, IPS, Database +

Application Firewall, VPN, DDOS Prevention)

Front-End

• Currently investigating WireCloud

20

Back-End

• Currently being assessed, most probably including• Mediator GE• Cloud Mgt GE• …

21

Overview & Aim Design, specify and provide a

conceptual prototype of the ‘Collaboration Manager’

• Envisioned Capabilities• Central management of all

relevant information for the execution of multi-party logistics processes (enabling global view)

• Facilitating consistent data management and information privacy throughout T&L business networks

• Exploiting entity-centric modeling as new ‘approach’ for enabling this

Business Collaboration Module – BCM (1)

22

Business Collaboration Module (BCM)

Notification & Action Trigger

Standard Process Repository

Process Engine

Collaboration ObjectManager

External Data

Importer

Secu

rity

& P

rivac

y M

anag

er

Notifications & Requests

Additionaltransport relevant

dataTransport plan

User Information & Profiles

BCO events Monitoring event types

Final Transport Status

CollaborationObject Storage

TransportEvents

Potential GEs from the initial FI-WARE architecture:• Big Data GE [Data/Conext Management]

• Used to persist Collaboration Object instances• GE consists of 3 component: data stream analysis, high-performance distributed

file system, NoSQL document-oriented storage• Latter: Used to store CO instances in a serialized and document-oriented

manner (JSON or XML); also graph-based storage possible• First: Used to run business analytics and analyze big amounts of stored COs

(not focused by FInest so far, but definitely desirable for the future)• Concern: Although NoSQL databases focus on read&write heavy scenario (which

the persistence of COs should be; vast amount of changes on COs during runtime), they do not ensure ACID principles

• Especially, not ensuring Consistency can be an issue• Possible Solution: Use special data access middleware that ensures data

consistency (e.g., Spring transaction management)

Business Collaboration Module - BCM (3)

24

Potential GEs from the initial FI-WARE architecture:• Pub/Sub [Data/Conext Management]

• Used to facilitate communication between EPM and BCM• GE allows BCM to subscribe to special events published by EPM• Also events published by BCM (for UI for instance) can be published• Concerns:

• GE requires a specific data model to support functionality; have to be compliant to our internal data model

• But: Seems to be generic enough so that the likelihood of problems should be rather low

• Publish/Subscribe patterns have to meet our requirements• Currently 2different mechanism are supported: Broker/Provider, Source/Consumer;

latter seems to meet our requirements

Business Collaboration Module - BCM (4)

25

Transport Planning Module – TPM (1)

27

Overview & Aim Aim: Design, specify and provide a

conceptual prototype of the ‘Transport Planning Module’

• Envisioned Capabilities• Describe how the TPM can

contribute to the collaboration platform to achieve more efficient planning processes

• Creation and maintenance of Transport Execution Plan (TEP) through usage of:

• Updated Status Information• Updated Transport Services

and Transport demand• Utilization of marketplace

functionality including match making

InterfaceManager

Transport Planning Engine

TransportDemand

Replanning

Transport Search/

Optimization/Selection/

Configuration

TCP to BCM and ECM

(Re)-planning trigger from BCM

R

Transport Planning and Re-planning Module (TPM)

Contract and TSD/Marketplace searchContract and TSD/Marketplace details

TPM Storage

TransportBooking

TEP requests to Booking SystemsTEP response from Booking Systems

R

Transport Demand

R

Transport Demand Updates

LSCTSD, TEP and TCP

Maintenance

Frontend/Backend


29

Potential GEs from the initial FI-WARE architecture -1 1. GE for storage of Transport Execution Plans to be accessible on the cloud: Select one of

the following:1. Apps.Repository: This is more for storing ICT services, file system with metadata, serialization

must be done manually.2. Cloud.ObjectStorage: Only for fixed data, no sql queries, no updates, only insert, delete,

includes metadata.3. Cloud.DCRM: Use Virtual Machine functionality from the Data Center Resource Management

GE to host an ordinary database in a VM: Then, we have ordinary database functionality, need to build the image, the stack, can use scaling mechanisms to add more resources.

4. Data.BigData : No ACID transactions, only BASE transactions


30

Potential GEs from the initial FI-WARE architecture -21. GE with TP monitor properties/transaction manager properties/orchestration/2phase-

commit for accessing heterogeneous booking systems (invoke several 3rd party systems for booking, ensuring that all or none of the bookings are committed):

1. Apps.Mediator: The set of booking systems to be accessed varies from one transport plan to another. We do not know the set of booking systems to access in advance.

2. Apps.Registry: Needed to store reference to various booking systems.3. Apps.CompositionExecution: We do not know the set of booking systems to access in

advance.4. Others?

Requested Generic Enablers• Optimization Models and Execution: Set up optimization models and execution of the

models• The proposed GE on Transaction Non-Repudiation: Using this to ensure secure

message exchange would help very much in the two-phase commit process of booking.


32

Event Processing Module – EPM (1)

33

Overview & Aim Collect events from various

sources, and perform what is known as complex event processing (CEP) on them • by detecting situations

of interest based on the logistic plan, and notify them to the business collaboration module (BCM) or FInest front-end.

• Objective: Provide end-to-end visibility and monitoring of the logistic processes and the ability to respond to changes and deviations in a timely manner.

Event Processing Module (EPM)

…Running Process

Status

Event)Source 1(

Event)Source n(

Detected Situation

Monitoring requirements

Runtime engine

Rules Rules definition

Event Processing Module – EPM (3)

35

Potential GEs from the initial FI-WARE architecture• Publish/Subscribe Broker GE (Data/Context chapter) – addresses required capabilities

#1-3• Complex Event Processing (CEP) GE (Data/Context chapter) – addresses required

capabilities #4

Requested Generic Enablers capabilities1. IoT Event Subscription: Subscription mechanism to events or data produced by things

such as devices or sensors2. Capture and Collect Events: Collect data from various sources 3. Disseminate Derived Events: Allow distribution of events to consumers which are

interested in that event. 4. Event Processing: Configurable event processing engine 5. Advanced Analytics: e.g. mining, predictive models, optimization engines, that can be

linked to FInest proactive event-driven capabilities

eContracting Module – ECM (1)

36

Overview & Aim Support logistics

stakeholders in semi-automatically establishing and managing contracts.

eContracting Module – ECM (3)

38

Potential GEs from the initial FI-WARE architecture• Application/Services Ecosystem & Delivery

• *USDL Tooling for modeling of logistics contracts (does not have interfaces)• *Repository• *Registry• *Marketplace• * Store (no interfaces provided so far….)• Mediator

• Data/Context Management Architecture• Metadata Processing• Pub/Sub (when extended to work associated with CEP, i.e., 2nd release)

Requested Generic Enablers• Epic: SLA & Contracts Storage and Retrieval: Store SLAs and contracts and mechanisms to retrieve

information from those SLAs and contracts

Potential requests for User Stories• Refine the interfaces for search in the Registry GE• Refinement of interfaces from Marketplace GE

*Primary GEs to be used by ECM

www.finest-ppp.eufinest-ppp.blogspot.co.uktwitter.com/#!/FInestPPP

The research leading to these results has received funding from the European Union's Seventh Framework Programme FP7/2007-2013 under grant agreement 285598 (FInest)

Documents

FI PPP ArchB Contact: Andreas Metzger Paluno, U Duisburg-Essen FInest Architecture