IT Basics for Supply Networks IT Basics for Supply Networks/4 Dr. Withalm 16-Oct-15.

IT Basics for Supply NetworksIT Basics for Supply Networks

IT Basics for Supply Networks/4IT Basics for Supply Networks/4

Dr. Withalm Apr 21, 2023

IT Basics for Supply Networks21.04.23 Dr.Withalm2

Lectures at the University of Bratislava/Autumn 2014

30.09.2014 Lecture 1 Introduction in CNO’s & Basics of Supply Networks

07.10.2014 Lecture 2 Kanban & Essential Supply Chain Processes

21.10.2014 Lecture 3 Business Processes & Semantic Web

11.11.2014 Lecture 4 SOA and SOA basing on J2EE

18.11.2014 Lecture 5 B2B & Cloud Computing including SaaS


Today’s Agenda

Overview of SOA SOA and WS and related Technologies Future of WEB Applications Event-Driven Business Processes

SOA basing on J2EE Change of Architectures SOA Concept SOA in J2EE Servlets Portlets Implications

Special Acknowledgment to Mr. Roger Zacharias who developed the concept of SOA in J2EE and is heading the Xing Network


Summary of first lecture

Progress in Architecture are primarily enabled by technology i.e. distributed computing by PC & Ethernet

Distributed computing encouraged Middle ware i.e. RPC, CORBA, DCOM-which work efficient in EAI-projects

Middle ware is kept enclosed within companies mainly because of “closed” ports i.e. most serious obstacle when deploying CORBA applications in IAI

projects EJB tried to combine strenghts of ORB and TP

Overcoming the performance issue which requested huge programming efforts in CORBA applications

EJB made a first “implicit” step towards services i.e. Session Beans-whenever their focus was mainly IT-focused and not

business oriented.


Summary of lecture 2

Business needs request Web Services

EAI : enables the integration of different applications within a company

Prevailing standards/technologies are CORBA, COM,..

Web Portals: enable Internet users to order products/services

Prevailing standards/technologies are HTTP, CGI, Servlet, Applets

Web Services: enable different applications to order products/services

Standards are the dark side of WS

Different standardization bodies: influenced by the big vendors

Most used and established are : SOAP, WSDL, and UDDI

SOA: enables not only synchronous mode

Semantic Web: Ontology, Agents and Languages as OWL, RDF

Ontology: most likely to be established in specific domains

Obstacles : not only technical but also political


Service-Oriented Architecture

Developers will shift their focus to business processes and away from software functionality. Software will become a facilitator of rapid business change, not an inhibitor.

The value creation in software will shift to subscription services and away from packaged software, and to composite applications (i.e., best of breed) and away from monolith suites.

(Source: Gartner August 2005)


Service Oriented Architecture (SOA)/1

The term Service-Oriented Architecture (SOA) expresses a software architectural concept that defines the use of services to support the requirements of software users.

In a SOA environment, nodes on a network make resources available to other participants in the network as independent services that the participants access in a standardized way.

Most definitions of SOA identify the use of Web services (using SOAP and WSDL) in its implementation.

However, one can implement SOA using any service-based technology.


Service Oriented Architecture (SOA) /2

Unlike traditional object-oriented architectures SOA comprise loosely joined, highly interoperable

application services. Because these services interoperate over different

development technologies (such as Java and .NET), the software components become very reusable.

SOA provides a methodology and framework for documenting enterprise capabilities and can support integration and consolidation activities.

SOA is not a product, although several vendors offer products which can form the basis of a SOA.


Service Oriented Architecture (W3C)

A distributed system, consists of discrete software agents that work together to implement some intended functionality. Those agents in a distributed system communicate by hardware/software protocol stacks.

Transport

Service

Description


SOA Core Principles

Business Driven The business drives the services, and the services

drive the technology. Bussiness Agility

Business agility is a fundamental business requirement.

Constant Change A successful SOA is always in flux.


Business Driven

The business drives the services, and the services drive the technology.

In essence, services act as a layer of abstraction between the business and the technology.

The service-oriented architect must understand the dynamic relationships between the needs of the business and the available services on the one hand, as well as the technical underpinnings that offer the layer of abstraction required by the services.


Business Agility

Business agility is a fundamental business requirement.

Instead of dealing with concrete requirements from

business, SOA considers the next level of abstraction:

The ability to respond to changing requirements is

the new ''meta-requirement.''

The entire architecture -- from the hardware on up --

must reflect the business agility requirement.


Constant Change

A successful SOA is always in flux.

To visualize how a SOA is supposed to work, it is better to think of a living organism or an ecosystem rather than the traditional ''building a house'' metaphor that gave software architecture its name.

IT environments are in a constant state of change, so the

work of a service-oriented architect is never done.


The Service Fabric

All different services available inside or outside an organization can be seen as a large network of computing resources where each node is providing a distinctive service to users and programs alike – the network becomes a service fabric – the ecosystem for the enterprise.


The New Application

The application as a network of services - the whole is more than the sum of its parts…


Vision

The future of the application is the virtual collection of services based on the Service Oriented Architecture developed and enhanced on demand and made available for service consumption in the service fabric of the Internet of tomorrow.


Service Categories

User (Interface) Services Business (Logic) Services Data (Backend) Services


User Services

UserService

BusinessService

BusinessService

BusinessService


Business Services

The programmatic access of a service and its (business) functionality is the main aspect of a service - often called a Business Logic Service.

This Business Service has to provide a distinctive service to its service consumers and can utilize other services to fulfill its task.

BusinessService


Data Services

The data store is accessed through standardized protocols and is exchanging data in XML format.

BusinessService

Data (Backend) Service


Service Manager Pattern

The service manager acts not only as a proxy for the business component but depending on the capabilities of the web server and

component container might also manage several other activities important to the delivery of web service

such as data and protocol translation, security, or state management.

ServiceClient

ServiceManager

ServiceImplementation


Aggregation

BusinessService

BusinessService

BusinessService

BusinessService


Integration

DataStore

BusinessService

Messages

Component


Orchestration

BusinessService

BusinessService

BusinessService

BusinessService


Services Orchestration and Choreography /1

No service is an island.

The key point about service-oriented computing is

that involves extended, loosely coupled activities

among two or more autonomous business partners.

Such activities can be thought of

as (business) processes that engage several services in a manner

that brings about the desired (business) outcome.



Web services are rapidly emerging as the most practical approach

for integrating a wide array of customer, vendor, and business-partner applications.

While many companies have begun to deploy individual Web services,

the real value will come when enterprises can connect services together,

providing higher value to an organisation.



In order to communicate and integrate services

for achieving a collaboration between enterprises,

it will be necessary to coordinate them,

which involve the necessity of offering support to the services composition.

Early experience shows that to make the most of new Web services investments

there must be a standard approach to Web services composition.


Services Orchestration and Choreography /4Orchestration/1

Refers to an executable business process

that may interact with both internal and external Web services.

Orchestration describes how Web services can interact at the message level,

including the business logic and execution order of the interactions.


Services Orchestration and Choreography /5Orchestration/2

These interactions may span applications and/or organisations,

and result in a long-lived, transactional process.

With orchestration, the process is always controlled

from the perspective of one of the business parties.

It takes the view of a process as a program or a partial order of operations

that need to be executed.


Services Orchestration and Choreography/6Choreography/1

More collaborative in nature,

where each party involved in the process

describes the part they play in the interaction.

Choreography tracks the sequence of messages

that may involve multiple parties and multiple sources.


Services Orchestration and Choreography/7Choreography/2

It is associated with the public message exchanges

that occur between multiple Web services.

this takes the view of a process as being

a set of message exchanges between participants.


Services Orchestration and Choreography/8



Orchestration differs from choreography in that it describes

a process flow between services,

controlled by a single party.

More collaborative in nature (see above Figure),

choreography tracks the sequence of messages

involving multiple parties,

where no one party truly “owns” the conversation.



It could be distinguished as Orchestration defines procedure

and Choreography defines protocol.

Above figure shows this issue,

where in "orchestration" there is a defined flow of processes

that will be executed,

and in "choreography" each WS knows

how it should act when an event comes in.


Aggregation Tier

PresentationService

AggregationService

Presentation Tier

Aggregation Tier

Business Logic Tier

Data Tier

BusinessService

BusinessService

DataService


ObjectProgram

ComponentHomogeneous Application

Service-Oriented ArchitectureSmall Enterprise, Complex Applications

Web ServicesB2B Market, Global Enterprise

ORB

MOM

Typical Access Via:

OOD

CBD

SOA

Tim

e

HTTP + XML

Evolution of Application Deployment Styles

Source: 2003


Programming Paradigm

It is there and running, simply connect and use.

Print Service

Service Consumer

Archiving Service

Back Office Service

Put together to build a complex device

Wire together to build a small device

Programming Paradigm

Object Orientation:Aligned with fine-grained business objects Reuse of source code based on the notion of typesIncreased maintainability and modifiability of the program code through encapsulationComponent Orientation:Aligned with mid-grained business functions Reuse based on prefabricated, executable codeIncreased maintainability and modifiability of the application through compositionService Orientation:Aligned with coarse-grained business processesFlexibility and extensibility through composition, federation, and orchestration of servicesIncreased interoperability and scalability through loose-coupling

Real World Analogy


Programming Approaches/1Declarative programming

describes only the problem inference mechanism tries to solve the problem

described provided by the respective program runtime

environment e.g. Prolog


Programming Approaches/2Event-driven programming

reacts to outside events and takes corresponding action typical programs developed with this approach include

graphical user interfaces that react to user input control programs that react to external environmental

conditions, e.g. to changes in temperature


Programming Approaches/3Procedural programming

Represents a sequential algorithm which is being executed step by step

The execution of the algorithm is governed by data which can also be modified by the algorithm


Programming Approaches/4Structured programming

Extension of procedural programming The main problem is broken down into several sub problems

each sub problem is solved Advantage: considerable simplification of individual algorithms

functions, procedures or modules The overall program is also easier to maintain and service


Impact – Development / Project Management

Keeping InvestmentsSmall (Changes)Focus is KnowledgePlatform AgnosticArchitecture Centric

More like CMOngoing ActivityFocus is OperationBusiness Driven


Service-Oriented Architecture

Develop Orchestrate

DeploySecure

Access

Integrate

Manage

Analyze


ROI Improvements

ROI

Time

Objects

Components

Services


Component Concepts

Topics

Standardization Proprietary Proprietary Open

Coupling Tight Tight Loose

Granularity Fine Fine to Coarse Business relevant

Implementation Monolithic Separate Independent

Interfaces Defined Formal Contractual

Objects Components Services


Componentization

ROI

Time

Custom

EAI

Services


Componentization Concepts

Topics

Standardization Proprietary Proprietary Open

Separation Applicationspecific

Applicationindependent

Implementationindependent

Scope Internal Some external Internal/External

Custom EAI Services


Evolution of SOA

Scope

Granularity

Events

Services

Components

Methods

Subroutines

TechnicalComponents

BusinessComponents

Affinity withBusiness Models

(Source: Gartner)


Defining ‘Event’

Ordinary event: Something that happened in the real world. A large or small change in the state of the universe.

Ordinary business event: A meaningful change in the state of the enterprise or of something relevant to the enterprise, such as a customer order, an employee address change, the arrival of a shipment at a loading dock, a bill payment or a truck breakdown.

Software event: A binary record of an ordinary event. Data, often packaged in the form of a message or electronic document, that describes an ordinary event.

(Source: Gartner)


Event-Driven Business Processes

Conventional: Build-to-stock Event-driven: Build-to-order

Conventional: Static pricing Event-driven: Yield management through dynamic pricing

Conventional: Periodic reports and ad hoc inquiry Event-driven: Supply chain monitoring

(Source: Gartner)


Events Are Already Applied in Many Ways

Event-Driven Business Processes (With or Without Computers) Work is triggered by a stimulus from outside.

Event-Driven (or “Message-Driven”) Application Systems An application system organizes its flow around the sending and receiving

of computer events.

Event-Driven System Software Operating systems use event loops to schedule and dispatch internal

services; management tools track the status of hardware and software components by listening to events.

Event-Driven Function in an Application Program A particular section of a GUI application is triggered when a mouse is

clicked on the associated screen icon.

(Source: Gartner)


Business Components: Service-Oriented

Service-Oriented Architecture Interaction Uses interface metadata One-to-one connections Client directs flow Data flows are predictable and linear Closed to unforeseen input once process begins

Client Server

InterfaceProxy

InterfaceStub

(Source: Gartner)


Business Components: Event-Driven

Event-Driven Notification Uses event descriptor metadata Many-to-many connections Sink (recipient) determines flow of logic Dynamic, parallel, asynchronous flows Can react to new external input while process is in

flight

Source SinkEvent

(Source: Gartner)


Business Component Architecture

SOA Interaction Coupled Conversational Subordinate Closed-ended

EDA Notification Decoupled Notification/subscription Autonomous Open-ended

(Source: Gartner)


Business Components - Five Patterns

SOA InteractionConversational

Request/Reply

ProgramA

ProgramB

“Microflow” Process

ProgramA

ProgramB

Call

Return

ProgramA

ProgramB

Send

Receive

ProgramA

ProgramB

Put

GetQueue

Event NotificationMessage Passing

Store and Forward

Publish and Subscribe ProgramA

ProgramB

ProgramB

Publish

Subscribe

Coupled

De-Coupled


Enterprise Service Bus (ESB)

An Enterprise Service Bus is an emerging standard for integrating enterprise applications in an

implementation-independent fashion at a coarse-grained service level (leveraging the

principles of service-oriented architecture) via an event-driven and XML-based¹ messaging

engine (the bus). An enterprise service bus generally provides an

abstraction layer on top of an Enterprise Messaging System which allows integration architects to exploit the value

of messaging without writing code.


ESB - Overview

In an ESB, applications and event-driven services are tied together in a loosely coupled fashion. This allows them to operate independently from one another while still providing value to a broader business function.


Service and Service Container

Ser vi ce

Service Container

Invocation and Management Framework

Service Endpoint

Service Messaging System(Enterprise Service Bus - ESB)

Methods

Service Interface


Service Variations

ESB

SOAP

HTTP

WS

Se

rv ice

Ap

plic

at io

n

Se

rv ice

Se

rv ice

We

b S

erv

ice

Ap

plica

t ion

Se

rv ice

Java

Java C# C++


System Configuration and Monitoring

Service Container

Invocation and Management Framework

Ap

plic

atio

n

Cu

sto

m

Serv

ice

We

b S

erv

ice

Brid

ge

Ad

ap

ter

HTTPXXXX

Cu

sto

m

Se

rvic

e

SystemConfiguration

System Diagnostics&

Monitoring

Discovery&

Configuration

ESB


Summary

Service Oriented Architecture (SOA) is an important step towards flexible and scalable solutions. Especially when seen not just as another RPC mechanism but rather as a message based communication means between business components.

The link with well-known Internet technologies is the foundation for the development of new applications and the backbone of integration with existing solutions.

The use of SOA and the integration of rich internet applications (RIA) is the cornerstone of the next generation of Web Applications.


Summary of lecture 3/1

Business focus is the main intention of SOA Direct mapping of business processes onto SW artifacts

Enabling very fast implementation of business processes Core principles of SOA

Business driven, business agility, and constant change Vision: the network is the application Service categories

User(interface) service, business(logic) service, and data(backend) service Aggregation of business services

Orchestration and Choreography Programming paradigms

Object orientation, component orientation, service orientation Programming approaches

Declarative, event driven, procedural, structured


Summary of lecture 3/2

Component concepts Objects, components, services

Componentization concepts Custom, EAI, services

Diference between conventional business processes and event driven ones Different business component architecture

SOA interaction and EDA notification Enterprise service bus

Ties together application and event driven services Enabling them to operate independently and providing values to a broader

business function Service container

Are already available-see exercises But for large implementations some important artifacts as system

diagnostics& monitoring are either missing or not higly reliable


Change of Architectures/1


Change of Architectures/2

Drivers of this change are New technologies

Java, J2EE, .NET, XML, and WS New Business Processes

Merger of companies, Acquisition of Companies, Globalization,CNO’s (Collaborative Networked Organizations), VO (Virtual Organizations).

If business and/or market react in 3 month cycles IT may not react in 18 month cycles

Ideally IT should map a whole business process Which comprehend all departments

Need to integrate systems and data within and between departments Serving different clients


Service Bus/1


Service Bus/2

Nowadays many systems with different applications and data must co-operate To meet a business management goal

Hence a service bus could be a most appropriate approach Enabling a maximum on flexibility

In above figure department A offers a service to department B Which is described in a contract and is subject

To specific conditions and constraints Merely the service providing is in the foreground

And the service provider is replaceable


SOA Concept/1


SOA Concept/2

In SOA you are only concerned with three parties Service provider

Provides services Registers them at the service registry of the service

broker Publishes them at service broker

Service Requester/Consumer Uses the available services Retrieves them at the service broker

Service Broker Administrates references of services at the service

registry Provides search functions to retrieve them


SOA /1Concept/1

One of the biggest benefits of SOA is the possibility to reuse Already existing services in new services

At any deepness of layering i.e. by aggregation of basic services value added

services will be generated The so called service aggregation (orchestration/choreography)

Which defines the order and conditions Under which complete independent from each other

services interoperate In order to realize a new service


SOA /2Concept/2

On this occasion new instruction standards are established As for instance the business process execution language (BPEL)

Business Process Execution Language Modeling with (BPMN) Business Process Modeling Notation

The long-term goal of these endeavors are Executable business process models

Which may be modeled by business process analysts The most well-known example for collaboration is

The combination of basic services as Flight reservation , reservation of accommodation and

charging of credit cards To the higher value service “travel booking”

A SOA service may be presented in different granularities From basic to complex work flow services-see next figure


Booking System for Flights

Booking System for Hotels

Credit Card System

Booking System for Travels

Client

Service Orchestration(Business Process)

SOA /3Concept/3


Essential Terms


SOA /33SOA in J2EE/1

At present there are neither standards or blue prints in

place

How SOA could be implemented in J2EE

Following a potential approach will be introduced

First of all the domain architecture will be described

And afterwards the mapping on a J2EE based

architecture



The fundamental approach is the structure of the

business management system

Into separate business components

Which represent closed/isolated cohesive units

These units may identified

By decomposition of the whole system

The term business component is more or less an artificial

term in the context of J2EE



For instance, a sale information system may be structured

in the following business components

Order processing, production planning, and sale

planning

Business components should be in any case

disintegrated

High cohesive

Business force of attraction of the parts

Minimal coupling

To parts of other business components



In that way it’s enabled to

Develop, analyze, and market/merchandize

The resulting IT-artifacts separately and in parallel

If a system requires more of these business components

It may be configured corresponding the specific customer

requirements and domain



Each business component specifies the accompanying

business process and data

For instance, a business component order processing

contains the following business services

Proposal processing, order processing, supply

checking

Invoice processing, and shipping processing

And manages data as

Customer, items, price, order, and invoice



The description respectively the specification of such a business

component

Together with their tasks, terminologies, behavior, quality

characteristics etc.

May be very efficient described

In respective part of this lectures

Introducing ARIS in Lecture 5



The business components have the following internal state Business services, which are aggregated to business processes Data entities, which are mapping business data

Concretely a business component contains business services A business process is aggregated by business services-see orchestration and

choreography A business process which is implemented as aggregation of business services is

independent of business components Case A: can aggregate services of different systems Case B: can aggregate services of different department business applications

(components) Case C: can aggregate services of one department business application

(component) Each business service provides

Operational SOA interfaces Which transform the system respectively the sub system from one consistent

state into an other



A business service will be realized by (at least) one

technical service

For instance, a business service check delivery could

exist of two operations

Check availability of product x

Check delivering time of product y



The external interface of a business component is the

sum of the service interfaces

Which will be applied by clients or other business

components

The business service itself contains the business logic

And uses to fulfill its tasks for instance other business

services

Within the same or other business components or

services of external systems



The data entity of a business component will be invariably

accessed Via the services of their business components

For the data access of other business components The respective external service will be used

The internal structure of a business component For fulfillment of a service is hidden from the service

consumer i.e. the data flow and the interactions of the

technical components


System

SystemClient

ExternalSystem

Business Component

BusinessComponent

BusinessService

SIA

Technical Service-Interface(RMI/IIOP, MDB,WebService, JCA Inbound MDB, Adapter, etc.)

Service Integration Adapter (SIA)(JCA Outbound, RMI/IIOP, RMI/JRMP, HTTP, WebServices,JMS, JavaMail, etc.).

can also actas system

client

PlatformService

System Client(Desktop, CLI, WebDesktop,

EXTS, etc.)

DTOtransferal

DTOtransferal

Data Entities:can be transient or persistent(CMP2, DAO)

DataEntity

BusinessService

Business Service:SLSB Facade as process interface

BusinessService-Interface



Abbreviations of above figure

CLI Command Line Interface

JMS Java Message Service

JCA Java Connector Architecture

MDB Message Driven Beans

DAO Database Access Object

DTO Database Transfer Object

SLSB StateLess Session Bean

RMI Remote Method Invocation

CMP Container Managed Persistence

JRMP Java Remote Method Protocol


Clients J2EE Server

RDBMSBusiness Interfaces

(Business Service Operations)

J2EEServices

• Transactions• Security• Integration• Persistence• Pooling• Concurrency • Component Infrastructure• Manageability• Availability• Scalability• Performance

Web Container

WebApp

HTML/HTTP

RMI/ IIOP

SOAP/HTTP

RMI/IIOP

MQ

BrowserClient

ITMP Database

ITMP Business Services

BusinessService

BusinessService

BusinessService

BusinessService

IIOP

C++Client

CORBAClient

JavaClient

MQClient

MQ Broker(e.g. MQSeries)

MQ

• Central business logic in terms of business services• Different service consumers:

• User on WebDesktop / Desktop / CLI• external system of a customer due to system integration • other internal service (orchestration/choreography)• triggered by internal Scheduler (Batch-Process)• triggered by Events from Agents• etc.

Example of Banking DivisionIT Management Productline (ITMP)

Technical Interfaces(RMI/IIOP, SOAP, JCA Inbound, MQ,

etc.)



Above figure shows the mapping of the business architecture on a technical architecture based on J2EE i.e. for each business artifact must be one or more

technical artifacts identified Which are able to fulfill the tasks of the business

artifacts As J2EE provides a component infrastructure

A business component will contain various technical components

The described system is mapped on an Enterprise Application Archive Which ultimately represents the application

Which contains all components



A business component containing business services and data entities Will be mapped on a Java package with appropriate sub packages

i.e. for interfaces, implementation, and data And will be packaged in a Java archive

The artifact business service will be mapped on a Session Bean Usually stateless

Which takes over the role of session facade For instance the transaction context

A facade is an object that provides a simplified interface to a larger

body of code, such as a class library



Within the session bean exists-dependent of the complexity

Various strategies for mapping the business logic of the business

service

The session façade may contain the business logic for the instance itself

Or apply to downstream application services

A data entity is mapped according to the application case

Either on local CMP (Container Managed Persistence)-entity beans

Or BMP (Bean Managed Persistence) entity beans together with data

access objects



The technical architecture must be completed by various artifacts In contrary to the business one

The first additional artifact is a platform service The service approach within a system should also be applied

To make use of the emphasized advantages For instance besides the existing caching, audit, and config

services A logging service together with operation logMessage() should

be provided Which are used by every system component

Which should nevertheless be decoupled from them



Primarily we are not interested in a maximal decoupling within a

system

In using XML

But we are more interested in the service approach

In which system internal communication artifacts should be

applied

And the interface must be published externally



The second artifact is an adapter to the outer world Which will be denoted as service integration adapter

This adapter publishes the services of the external system within the own system Must primarily provide a business interface

The implementation of the interface is directly dependent From the external system which should be integrated

And from the interfaces of this system which should be usable

It encompasses generated WSDL stubs until the exploitation of screen scraping technique A computer program extracts data from the display output of

another program



The third additional artifact is the technical interface

Which enables the technical accessibility of a service

adorning the business interface

A SOA service should be modeled independent

As much as possible from the client type

Reusing it in future contexts

Decoupling of technical and business interface will

accomplish it


SOA /51SOA in J2EE/19Usage of a service from various consumers



In above figure three different consumer applications are

introduced

Using the same service

An asynchronous client (message queuing client)

Calling the service by a message façade

asynchronously

Two synchronous clients accessing via

RMI/IOP

Web-Service



The respective client should only know for using the

service

the corresponding naming service

The business service ID

The business interface

Concerning the orchestration of the defined services

Different possibilities are in place



If a service should be used within compartment business process It is recommended to use

A specialized business process engine Which is calling the interfaces of the defined systems

On the respective positions within the process If services are used in a smaller environment (with a Web front

end) The business delegate will be used as composite service

respectively as service choreographer



Each service oriented system can be described

completely on a high level

With help of these defined components

Each of them are own stereotyped assigned

The description is performed both static and dynamic

(UML) Component, Deployment, and Interaction

Diagrams



The description can be applicable because of the high

level of abstraction

For the communication of all system stake holders

i.e. customer, management, development

Furthermore a traceability of the requirements is enabled

From the business and technical architecture to the

code

As the described business artifacts are directly

mapped on the technical ones



Of course a unique naming for one and the same artifact

is mandatory

On all phases of the development process

When Model Driven Architecture (MDA) is broadly applied

This approach is clearly simplified



The application of object-component-service concept Are shown by this approach

A J2EE application can be taken to respective tiers Where each of these tiers corresponds to one of these

concepts See the following figure

So we can’t speak of replacing but of complementary approach

The difference is merely the granularity Of the respective interfaces And in the level of abstraction


SOA /61Implications/3Abstraction pyramid- Artifacts


SOA /59Implications/1

The evolution from the contemporary to SOA

Will presumably have the following impacts

The level of abstraction for developing application

software will be increased

Especially in combination with the MDA approach

i.e. the development of business applications will

require fewer detailed technical knowledge

And becomes in that way more efficient



Of course these statement are more or less marketing As new approaches usually are more promising

As finally will be reached But with each new approach target comes closer More efficient doesn’t mean that an application will be

developed in half the time As experience have shown time for development stays

constant As with a simplification of methods/tools the

complexity of systems increases i.e. imagine the realization of an online booking

system with Assembler instead of J2EE



SW-development in future will still take place on different

levels (see following figure)

With the most specialized tools, patterns, and IT-

specialists

Starting by development (firm ware) via

Development of operating systems

Development of middle ware

Real application development


SOA /62Implications/4 Abstraction pyramid- Patterns



Application development is also structured in three layers

A layer of application framework with defined platform

services

Applications of pure business aspects

Which uses the application framework

Layer of choreography where orchestrating is

predominating

For mapping comprehensive business processes



It means that new business processes supporting IT-

systems

Must not be developed from scratch

But may build up on already existing layers

i.e. middle ware of application servers



As every other approach also SOA has some

weaknesses

Some are evident today

Some become aware during development

And some become aware years after employment

The most severe problem is the wrong application of the

SOA concepts

And the resulting conclusion

Also in the J2EE area some projects failed



If the realization of SOA is merely seen as Web-service technology And XML communication between services within a

server is used Performance problems will arise

Also the inter-system communication is backing at present merely on Web-Services As horizontal services are not comprehensive

specified i.e. propagation of transaction context and cluster

awareness And such services must be developed by oneself



Furthermore the added value will stay out

If there is no direct mapping of business service on

technical services

But only a technical-oriented approach will be

distinguished

Disputes between enterprises are predictable

If a service liable to pay costs is assembled of three

services exempt from charges

And afterwards is highly profitable



To solve this issue a respective accounting infrastructure

for SOA must be established

Presumably the IT-management of SOA systems is more

challenging

As for the coverage of a business process any

systems must interact

In contrary to a monolithic system there must be for

instance 30 services exist

i.e. 30 service level agreements must be concluded



In extreme case the danger of a system chaos exists

With an exponential increasing of system complexity

As millions of networked services are built

And the control flow on the whole

Is distributed over various instances

And in that way hardly comprehensible

IT Basics for Supply NetworksIT Basics for Supply Networks

Thank youfor your attention!


Farbpalette mit Farbcodes

Primäre Flächenfarbe:

R 215G 225B 225

R 130G 160B 165

R 170G 190B 195

R 220G 225B 230

R 145G 155B 165

R 185G 195B 205

R 255G 210B 078

R 229G 025B 055

R 245G 128B 039

R 000G 133B 062

R 000G 000B 000

R 000G 084B 159

R 255G 255B 255

Sekundäre Flächenfarben:

Akzentfarben:

R 255G 221B 122

R 236G 083B 105

R 248G 160B 093

R 064G 164B 110

R 064G 064B 064

R 064G 127B 183

R 255G 232B 166

R 242G 140B 155

R 250G 191B 147

R 127G 194B 158

R 127G 127B 127

R 127G 169B 207

R 255G 244B 211

R 248G 197B 205

R 252G 223B 201

R 191G 224B 207

R 191G 191B 191

R 191G 212B 231

R 255G 250B 237

R 252G 232B 235

R 254G 242B 233

R 229G 243B 235

R 229G 229B 229

R 229G 238B 245

IT Basics for Supply Networks IT Basics for Supply Networks/4 Dr. Withalm 16-Oct-15.

Documents

Transcript of IT Basics for Supply Networks IT Basics for Supply Networks/4 Dr. Withalm 16-Oct-15.