SOA Bratislava SOA Part1 Lecture 4 Dr. Withalm 24-Aug-15.

SOA BratislavaSOA Bratislava

SOA Part1 Lecture 4SOA Part1 Lecture 4

Dr. Withalm Apr 19, 2023

19.04.23 Dr.Withalm2 SOA Bratislava

Lectures at the University of Bratislava/Autumn 2011

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

26.09.2011 Lecture 2 Kanban & Essential Supply Chain Processes

10.10.2011 Lecture 3 Business Processes & Semantic Web

17.10.2011 Lecture 4 SOA and SOA basing on J2EE

14.11.2011 Lecture 5 B2B & Cloud Computing


Today’s Agenda

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


Servlets/1 Development

Servlets are influenced both by applets and by CGI

CGI is a server-side technology• Program calls and parameters are passed on to the web

server via a standardized interface; the web server then

ensures the respective programs are executed as separate

operating system processes Applets are small applications executing on the client

• Applets are loaded into the client’s browser by the web

server and then executed


Servlets/2 Characteristics/1

Basically, Servlets are the server-side equivalent of applets also written in Java but executed on the server like CGI scripts after being called

up by a browser or its user in contrast to CGI, however, the web server does not start a

separate process Servlets are

• executed with the help of a servlet engine

• integrated into the web server

• Many web servers are capable of executing Servlets



The servlet technology is provided in the form of a class library (API)

Access to client requests and to further environment variables is provided

the response is written into a data stream and returned to the client

Cookies, which the server uses to store user-specific information on the client and then upload it again during the next session, are supported



Sessions that enable a connection between client and server to be kept up beyond a single HTTP request are also supported

API does not define whether the application as such (which is usually accessed via Servlets) executes in the same process as the web server or maybe even on a different computer


Servlets/5 Architecture/1

Web server

Servlet engine

S

S

Tier 1: Presentation Tier 2: Web server/servlets Tier 3: Legacy application



In tier 1 on the client side, web browsers run as presentation programs

requests are passed on to the web server by entering an URL or clicking on links

the web server detects that the URL it received encodes a servlet call

the call is passed on to the servlet engine, which then executes the servlet in question



The parameters received from the client

must be converted into the application’s language this converted request must then be passed on to the

application in tier 3



Application in tier 3 processes the request produces a result returns the result to the servlet by using the Java

methods contained in the Servlets

The servlet converts the result back into the language of the web browser, i.e. HTML, and sends it to the client, which finally presents the result in its output window


Servlets/10 How a servlet call works/1

Client Web server Application

Result of request:The following database recordsare available:

Miller: 3023 DMJones: 5032 DM

Execution

Servlet

Send formtriggers HTTP request

waits

Pass on via

HTML/HTTP Servlet

through engine

waits

Execute program

Return results

via API

Application


Portlets/1

In contrast with Web-Services

which are computer-to-computer services

Presentation Oriented Services provide a user interface

that allows an end-user to interact directly with the service.

Two main standards exist

the JSR 168 specification

and the Remote Portlets specification.


Portlets/2 JSR/1

The Java Portlet Specification (JSR-168) defines a standard API for J2EE-based portal platforms.

The goal of JSR-168 is to provide a set of standards

so that any compliant portlet can be deployed

on any portal which supports the specification.


Portlets/3 JSR/2Overview/1

Container Contract Besides life cycle methods (init,..) some specific

methods as process action and render are specified Portlet mode and window state

Indicating functions and space for a portlet Portlet preferences

Enabling custom view or behavior for different users User information

Providing user information as name, e-mail,..


Portlets/4 JSR/3Overview/2

Packaging and deployment Is specified as part of the WAR (Web Application

Archive) Security

For instance restricting portlet be running only over HTTP or authentication functions

JSP Tag Library Enabling to display portlet pages with JSP technology


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

SOA BratislavaSOA Bratislava

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

SOA Bratislava SOA Part1 Lecture 4 Dr. Withalm 24-Aug-15.

Documents

Transcript of SOA Bratislava SOA Part1 Lecture 4 Dr. Withalm 24-Aug-15.