IT Basics for Supply Networks/4

1
IT Basics for Supply Networks/4
Dr. Withalm 7-Feb-15
2
Lectures at the University of Bratislava/Autumn
2014

• 30.09.2014 Lecture 1 Introduction in CNOs
  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

3
Todays 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

4
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.

5
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

6
Gartner Analyzes Hottest Topics of 2005

• The topics include open-source software,
  voice/data convergence, service-oriented
  architecture, IT utility, and global sourcing.
• "These five trends represent inevitable and
  irrevocable shifts in the information technology
  landscape,"
• "Service oriented architecture (SOA), open source
  software (OSS) and IT utility together drive a
  fundamental change in how applications are built
  and delivered,"

(Source Gartner August 2005)
7
Hype Cycle for Emerging Technologies, 2005
(Source Gartner August 2005)
8
Service-Oriented Architecture

• By 2006, more than 60 percent of the 527 billion
  market for IT professional services will be based
  on Web services standards and technology.
• By 2008, 80 percent of software development
  projects will be based on SOA. The distinction
  between software integrators and vendors will
  blur as packaged applications are broken apart
  and delivered as service-oriented business
  applications.

(Source Gartner August 2005)
9
Gartner Predictions (2007)

• It will be difficult to buy a nonwireless
  device.
• Secure, robust, national wireless broadband
  networks will reach critical mass.
• It will be nearly impossible to buy a cell phone
  without a camera.
• Electronic paper will be a viable alternative to
  paper for industrial and consumer applications.
• Applications will be built by assembling
  services.
• Core infrastructures of computing and storage
  will be much more autonomic and reliable.
• The last new application for Unix will have been
  written.
• RFID will be ubiquitous up to the retail shop.
• The wireless digital media center will be the de
  facto home form factor.
• Real-time analytics and massive data management
  will emerge as the most important business
  applications.

SOA
10
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)
11
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.

12
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.

13
Service Oriented Architecture (W3C)
Service
Transport
Description
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.
14
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.

15
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.

16
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.

17
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.

18
Service Eco-System
19
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.

20
Ecosystem of Services
21
The New Application

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

22
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.

23
The network is the application
24
Service Categories

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

25
User Services
26
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.

Business Service
27
Data Services
Data (Backend) Service
Business Service

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

28
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.

Service Client
Service Manager
Service Implementation
29
Aggregation
Business Service
Business Service
Business Service
Business Service
30
Integration
Data Store
Business Service
Component
31
Orchestration
Business Service
Business Service
Business Service
Business Service
32
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.

33
Services Orchestration and Choreography /2

• 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.

34
Services Orchestration and Choreography /3

• 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.

35
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.

36
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.

37
Services Orchestration and Choreography/6Choreogr
aphy/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.

38
Services Orchestration and Choreography/7Choreogr
aphy/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.

39
Services Orchestration and Choreography/8
40
Services Orchestration and Choreography/9

• 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.

41
Services Orchestration and Choreography/10

• 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.

42
Aggregation Tier
43
Evolution of Application Deployment Styles
Typical Access Via
Web Services B2B Market, Global Enterprise
HTTP XML
Service-Oriented Architecture Small Enterprise,
Complex Applications
Time
MOM
SOA
ComponentHomogeneous Application
ORB
ObjectProgram
CBD
OOD
44
Programming Paradigm
Programming Paradigm
Real World Analogy
Object Orientation Aligned with fine-grained
business objects Reuse of source code based on
the notion of types Increased maintainability and
modifiability of the program code through
encapsulation
Component Orientation Aligned with mid-grained
business functions Reuse based on
prefabricated, executable code Increased
maintainability and modifiability of the
application through composition
Service Orientation Aligned with coarse-grained
business processes Flexibility and extensibility
through composition, federation, and
orchestration of services Increased
interoperability and scalability through
loose-coupling
It is there and running, simply connect and use.
Archiving Service
45
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

46
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

47
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

48
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

49
Impact Development / Project Management

• Keeping Investments
• Small (Changes)
• Focus is Knowledge
• Platform Agnostic
• Architecture Centric

• More like CM
• Ongoing Activity
• Focus is Operation
• Business Driven

50
Service-Oriented Architecture
Develop
Analyze
Access
Manage
51
ROI Improvements
ROI
Services
Components
Objects
Time
52
Component Concepts
Topics
Objects
Components
Services
Standardization
Proprietary
Proprietary
Open
Coupling
Tight
Tight
Loose
Granularity
Fine
Fine to Coarse
Business relevant
Implementation
Monolithic
Separate
Independent
Interfaces
Defined
Formal
Contractual
53
Componentization
ROI
Services
EAI
Custom
Time
54
Componentization Concepts
Topics
Custom
EAI
Services
Standardization
Proprietary
Proprietary
Open
Separation
Application specific
Application independent
Implementation independent
Scope
Internal
Some external
Internal/External
55
Evolution of SOA
Affinity with Business Models
Technical Components
Business Components
(Source Gartner)
56
The Evolution of Architecture
expectations
EDA
SOA
Monolithic Architecture
SOA EDA
time
Business Component Architecture
Technology Trigger
Peak of Inflated Expectations
Trough of Disillusionment
Slope of Enlightenment
Plateau of Productivity
(Source Gartner)
57
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)
58
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)
59
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)
60
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
Interface Proxy
Interface Stub
(Source Gartner)
61
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
Sink
Event
(Source Gartner)
62
Business Component Architecture

• SOA Interaction
• Coupled
• Conversational
• Subordinate
• Closed-ended
• EDA Notification
• Decoupled
• Notification/subscription
• Autonomous
• Open-ended

(Source Gartner)
63
Business Components - Five Patterns
Coupled
SOA Interaction
Conversational
Request/Reply
Event Notification
Message Passing
Store and Forward
Publish and Subscribe
De- Coupled
64
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.

65
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.

66
Service and Service Container
S
e
r
v
i
c
e
Methods
Service
Endpoint
Invocation and Management Framework
Service
Interface
Service Container
Service Messaging System (Enterprise Service Bus
- ESB)
67
Service Variations
S
A
A
e
p
p
r
p
p
v
l
l
i
i
i
W
c
c
c
e
e
a
a
t
t
b
i
i
S
S
S

o
o
S
e
e
e
n
n
r
r
r
e
r
v
v
v
i
i
i
v
Java
c
c
c
i
c
e
e
e
e
SOAP
Java
C

C

WS
HTTP
ESB
68
Service Collocation vs. Single Services
Collocated Services
A
B
d
r
W
A
i
a
p
d
e
p
g
p
b
t
C
C
S
S
l

e
e
i
u
e
u
e
S
r
c
r
r
s
s
e
a
v
v
t
t
r
t
i
i
o
o
i
v
c
c
o
i
m
m
e
e
S
S
c
n


e
e
e
XXXX
r
r
v
v
i
i
c
c
e
e
HTTP
Invocation and Management Framework
Service Container
ESB
69
System Configuration and Monitoring
A
B
d
r
W
A
i
a
e
d
p
p
b
g
p
t
C
C
S
S
l

e
e
i
e
u
e
S
u
r
c
r
r
s
s
e
a
v
v
t
t
r
t
i
i
o
o
v
i
c
c
o
i
m
m
e
e
c
n


e
XXXX
HTTP
System
Configuration
Invocation and Management Framework
Service Container
System Diagnostics
Discovery


Monitoring
Configuration
ESB
70
Service Implementation
Service
JVM
.
NET CLR
C

Runtime
Service
Implementation
Implementation
Components
Components
(
Java
,
.
NET
)
(
C
)
Java
C

C

OS
OS
OS
PC
PC
PC
71
Service Deployment and Scaling
Comp
.
-
Container
Service
OS
PC
Scaling
-
Up
Scaling
-
Out
72
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.

73
Useful Links

• SC CIT Web Sitehttp//cit.siemens.at
• World Wide Web Consortium (W3C)http//www.w3c.org
  
• W3C Web Services Activitieshttp//www.w3c.org/200
  2/ws
• OASIShttp//www.oasis-open.org
• WS-Ihttp//www.ws-i.org
• Gartnerhttp//www.gartner.com

74
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

75
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

76
Change of Architectures/1
77
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,CNOs (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

78
Service Bus/1
79
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

80
SOA Concept/1
81
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

82
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

83
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

84
SOA /3Concept/3
85
Essential Terms
86
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

87
SOA /34SOA in J2EE/2

• 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

88
SOA /35SOA in J2EE/3

• 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

89
SOA /36SOA in J2EE/4

• In that way its 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

90
SOA /37SOA in J2EE/5

• 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

91
SOA /38SOA in J2EE/6

• 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

92
SOA /39SOA in J2EE/7

• 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

93
SOA /40SOA in J2EE/8

• 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

94
SOA /41SOA in J2EE/9

• 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

95
SOA /42SOA in J2EE/10

• 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

96
SOA /43 SOA in J2EE/11
System
Business Component
DTO transferal
DTO transferal
Business Component
System Client
External System
Data Entity
can also act as system client
System Client (Desktop, CLI, WebDesktop, EXTS,
etc.)
Technical Service-Interface (RMI/IIOP,
MDB, WebService, JCA Inbound MDB, Adapter, etc.)
Business Service-Interface

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

Data Entities can be transient or
persistent (CMP2, DAO)
Business Service SLSB Facade as process interface
97
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

98
Example of Banking Division IT Management
Productline (ITMP)
Clients
J2EE Server
Web Container
J2EE Services
ITMP Business Services
Web App
Browser Client
HTML/ HTTP

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

RMI/ IIOP
Java Client
RMI/ IIOP
IIOP
CORBA Client
SOAP/ HTTP
C Client
MQ
MQ Client
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/choreograph
  y)
• triggered by internal Scheduler (Batch-Process)
• triggered by Events from Agents
• etc.

RDBMS
Business Interfaces (Business Service Operations)
ITMP Database
Technical Interfaces (RMI/IIOP, SOAP, JCA
Inbound, MQ, etc.)
99
SOA /44SOA in J2EE/12

• 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

100
SOA /45SOA in J2EE/13

• 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

101
SOA /46SOA in J2EE/14

• 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

102
SOA /46SOA in J2EE/15

• 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

103
SOA /48SOA in J2EE/16

• 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

104
SOA /49SOA in J2EE/17

• 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

105
SOA /50SOA in J2EE/18

• 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

106
SOA /51SOA in J2EE/19Usage of a service from
various consumers
107
SOA /52SOA in J2EE/20

• 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

108
SOA /53SOA in J2EE/21

• 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

109
SOA /54SOA in J2EE/22

• 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

110
SOA /55SOA in J2EE/23

• 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

111
SOA /56SOA in J2EE/24

• 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

112
SOA /57SOA in J2EE/25

• 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

113
SOA /58SOA in J2EE/26

• 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 cant speak of replacing but of
  complementary approach
• The difference is merely the granularity
• Of the respective interfaces
• And in the level of abstraction

114
SOA /61Implications/3Abstraction pyramid-
Artifacts
115
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

116
SOA /60Implications/2

• 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 doesnt 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

117
SOA /63Implications/5

• 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

118
SOA /62Implications/4 Abstraction pyramid-
Patterns
119
SOA /64Implications/6

• 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

120
SOA /65Implications/7

• 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

121
SOA /66Implications/8

• 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

122
SOA /67Implications/9

• 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

123
SOA /68Implications/10

• 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

124
SOA /69Implications/11

• 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

125
SOA /70Implications/12

• 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

126
Thank youfor your attention!
127
Farbpalette mit Farbcodes
Primäre Flächenfarbe
Akzentfarben
R 255 G 210 B 078
R 229 G 025 B 055
R 245 G 128 B 039
R 000 G 133 B 062
R 000 G 000 B 000
R 000 G 084 B 159
R 255 G 255 B 255
R 255 G 221 B 122
R 236 G 083 B 105
R 248 G 160 B 093
R 064 G 164 B 110
R 064 G 064 B 064
R 064 G 127 B 183
Sekundäre Flächenfarben
R 130 G 160 B 165
R 170 G 190 B 195
R 215 G 225 B 225
R 255 G 232 B 166
R 242 G 140 B 155
R 250 G 191 B 147
R 127 G 194 B 158
R 127 G 127 B 127
R 127 G 169 B 207
R 220 G 225 B 230
R 145 G 155 B 165
R 185 G 195 B 205
R 255 G 244 B 211
R 248 G 197 B 205
R 252 G 223 B 201
R 191 G 224 B 207
R 191 G 191 B 191
R 191 G 212 B 231
R 255 G 250 B 237
R 252 G 232 B 235
R 254 G 242 B 233
R 229 G 243 B 235
R 229 G 229 B 229
R 229 G 238 B 245