SOA Part1 Lecture 4 - PowerPoint PPT Presentation


PPT – SOA Part1 Lecture 4 PowerPoint presentation | free to download - id: 5dc2bf-NGVhY


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

SOA Part1 Lecture 4


Title: Pr sentationstitel Author: Withalm Josef Last modified by: withalm Created Date: 1/24/2006 2:04:33 PM Document presentation format: Bildschirmpr sentation – PowerPoint PPT presentation

Number of Views:11
Avg rating:3.0/5.0
Slides: 71
Provided by: Withal9
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: SOA Part1 Lecture 4

SOA Part1 Lecture 4
Dr. Withalm 20-Feb-15
Lectures at the University of Bratislava/Autumn
  • 19.09.2011 Lecture 1 Introduction in CNOs
    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

Todays 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
  • Enabling very fast implementation of business
  • Core principles of SOA
  • Business driven, business agility, and constant
  • 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
  • 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,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

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
  • 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
  • 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
  • As for instance the business process execution
    language (BPEL) Business Process Execution
  • Modeling with (BPMN) Business Process Modeling
  • 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
  • From basic to complex work flow services-see next

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
  • And afterwards the mapping on a J2EE based

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

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
  • Business components should be in any case
  • High cohesive
  • Business force of attraction of the parts
  • Minimal coupling
  • To parts of other business components

SOA /36SOA in J2EE/4
  • In that way its enabled to
  • Develop, analyze, and market/merchandize
  • The resulting IT-artifacts separately and in
  • If a system requires more of these business
  • It may be configured corresponding the specific
    customer requirements and domain

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
  • Proposal processing, order processing, supply
  • Invoice processing, and shipping processing
  • And manages data as
  • Customer, items, price, order, and invoice

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

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

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

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
  • And uses to fulfill its tasks for instance other
    business services
  • Within the same or other business components or
    services of external systems

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

SOA /43 SOA in J2EE/11
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,
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
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

Example of Banking Division IT Management
Productline (ITMP)
J2EE Server
Web Container
J2EE Services
ITMP Business Services
Web App
Browser Client
  • Transactions
  • Security
  • Integration
  • Persistence
  • Pooling
  • Concurrency
  • Component
  • Infrastructure
  • Manageability
  • Availability
  • Scalability
  • Performance

Java Client
CORBA Client
C Client
MQ Client
MQ Broker (e.g. MQSeries)
  • Central business logic in terms of business
  • Different service consumers
  • User on WebDesktop / Desktop / CLI
  • external system of a customer due to system
  • other internal service (orchestration/choreograph
  • triggered by internal Scheduler (Batch-Process)
  • triggered by Events from Agents
  • etc.

Business Interfaces (Business Service Operations)
ITMP Database
Technical Interfaces (RMI/IIOP, SOAP, JCA
Inbound, MQ, etc.)
SOA /44SOA in J2EE/12
  • Above figure shows the mapping of the business
    architecture on a technical architecture based on
  • 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

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

SOA /46SOA in J2EE/14
  • Within the session bean exists-dependent of the
  • 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

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

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
  • In which system internal communication artifacts
    should be applied
  • And the interface must be published externally

SOA /49SOA in J2EE/17
  • The second artifact is an adapter to the outer
  • Which will be denoted as service integration
  • 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
  • From the external system which should be
  • 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

SOA /50SOA in J2EE/18
  • The third additional artifact is the technical
  • Which enables the technical accessibility of a
  • 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
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
  • Two synchronous clients accessing via
  • Web-Service

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
  • Different possibilities are in place

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

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
  • (UML) Component, Deployment, and Interaction

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
  • From the business and technical architecture to
    the code
  • As the described business artifacts are directly
    mapped on the technical ones

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
  • This approach is clearly simplified

SOA /58SOA in J2EE/26
  • The application of object-component-service
  • Are shown by this approach
  • A J2EE application can be taken to respective
  • 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

SOA /61Implications/3Abstraction pyramid-
Servlets/1 Development
  • Servlets are influenced both by applets and by
  • 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
  • Applets are loaded into the clients 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/3 Characteristics/2
  • 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

Servlets/4 Characteristics/3
  • 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
Tier 3 Legacy application
Tier 1 Presentation
Tier 2 Web server/servlets
Servlets/6 Architecture/2
  • 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

Servlets/7 Architecture/3
  • The parameters received from the client
  • must be converted into the applications language
  • this converted request must then be passed on to
    the application in tier 3

Servlets/8 Architecture/4
  • 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
Send form
triggers HTTP request
Execute program
through engine
Return results
Result of request The following database
recordsare available Miller 3023 DM Jones
5032 DM
via API
Pass on via
  • In contrast with Web-Services
  • which are computer-to-computer services
  • Presentation Oriented Services provide a user
  • 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
  • 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
  • Portlet mode and window state
  • Indicating functions and space for a portlet
  • Portlet preferences
  • Enabling custom view or behavior for different
  • 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
  • Security
  • For instance restricting portlet be running only
    over HTTP or authentication functions
  • JSP Tag Library
  • Enabling to display portlet pages with JSP

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

SOA /60Implications/2
  • Of course these statement are more or less
  • 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

SOA /63Implications/5
  • SW-development in future will still take place on
    different levels (see following figure)
  • With the most specialized tools, patterns, and
  • Starting by development (firm ware) via
  • Development of operating systems
  • Development of middle ware
  • Real application development

SOA /62Implications/4 Abstraction pyramid-
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
  • For mapping comprehensive business processes

SOA /65Implications/7
  • It means that new business processes supporting
  • Must not be developed from scratch
  • But may build up on already existing layers
  • i.e. middle ware of application servers

SOA /66Implications/8
  • As every other approach also SOA has some
  • 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

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
  • i.e. propagation of transaction context and
    cluster awareness
  • And such services must be developed by oneself

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

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

SOA /70Implications/12
  • In extreme case the danger of a system chaos
  • With an exponential increasing of system
  • 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

Thank youfor your attention!
Farbpalette mit Farbcodes
Primäre Flächenfarbe
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