soa bratislava soa part1 lecture 1 dr. withalm 7-sep-15

SOA BratislavaSOA Bratislava

SOA Part1 Lecture 1SOA Part1 Lecture 1

Dr. Withalm Apr 21, 2023

21.04.23 Dr.Withalm3 SOA Bratislava

Lectures at the University of Bratislava/Autumn 2011

19.09.2011 Lecture 1 The long Way from OO to SOA & WEB- Services

26.09.2011 Lecture 2 Semantic WEB & SOA-Technological Basis

10.10.2011 Lecture 3 SOA-Basing on J2EE & SOA-Focus on Business Processes

17.10.2011 Lecture 4 B2B Frameworks and related Standards

14.11.2011 Lecture 5 WEB 2.0 & GRID & Cloud Computing


Today’s Agenda

Software Architecture

Programming Paradigm

CORBA

Application Server

TP Monitor

EJB

J2EE


Software Architecture

Software architecture is a coherent set of abstract patterns guiding the design of each aspect of a larger software system.

Software architecture underlies the practice of building computer software. In the same way as a building architect sets the principles and goals of a building project as the basis for the draftsman's plans, so too, a software architect or systems architect sets out the software architecture as a basis for actual system design specifications, per the requirements of the client.


Software Architecture Examples

There are many common ways of designing computer software modules and their communications, among them:

Distributed computing Client-server Peer-to-peer system Three-tier model Service-oriented architecture


Distributed Computing

There are many different types of distributed computing systems and many challenges to overcome in successfully architecting one. The main goal of a distributed computing system is to connect users and resources in a transparent, open, and scalable way.

This includes simple client-server system and extends up to grid computing. Grid computing uses the resources of many separate computers connected by a network (usually the internet) to solve large-scale computation problems.


Scalability

A scalable system is one that can easily be altered to accommodate

changes in the amount of users, resources and computing entities

affected to it. Scalability can be measured in three different dimensions: Load scalability — A distributed system should make it easy to

expand to accommodate heavier or lighter loads. Geographic scalability — A geographically scalable system is one

that maintains its usefulness and usability, regardless of how far

apart its users or resources are. Administrative scalability — No matter how many different

organizations need to share a single distributed system, it should still

be easy to use and manage. Some loss of performance may occur in a system that allows itself to

scale in one or more of these dimensions.


Client-Server

Client/Server is a scalable architecture, whereby each computer or process on the network is either a client or a server. Server software generally, but not always, runs on powerful computers dedicated for exclusive use to running the business application.

Client software on the other hand generally runs on common PCs or workstations. Clients get all or most of their information and rely on the application server for things such as configuration files, stock quotes, business application programs, or to offload compute-intensive application tasks back to the server.


Client-Server (cont.)

Properties of a server:Passive (Slave) Waiting for requests On requests serves them and send a reply

Properties of a client:Active (Master) Sending requests Waits until reply arrives


Client-Server (cont.)

WebServer

PrintServer

DirectoryServer

DatabaseServer

FileServer

MailServer


Peer-to-Peer

A peer-to-peer (or P2P) computer network is a network that relies on the computing power and bandwidth of the participants in the network rather than concentrating it in a relatively few servers.

A pure peer-to-peer file transfer network does not have the notion of clients or servers, but only equal peer nodes that simultaneously function as both "clients" and "servers" to the other nodes on the network.

A typical example for a non peer-to-peer file transfer is an FTP server. One user uploads a file to the FTP server, then many others download it, with no need for the uploader and downloader to be connected at the same time.


Three-Tier Model

Three-tier is a client-server architecture in which the user interface, functional process logic ("business rules"), data storage and data access are developed and maintained as independent modules, most often on separate platforms.

ApplicationTier

DataTier

User InterfaceTier


N-Tier Model

ApplicationTier

DataTier

User InterfaceTier



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


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


CORBA - OMG / 1

Largest SW-Consortium more than 800 members

System providers as: Siemens, IBM, HP, DEC, Oracle... End users as: Boeing, AT&T, Daimler Benz... From all branches as Telecom, Health, Finance...

21.04.23 Dr.Withalm SOA Bratislava

Distributed Objects, Corba Style / 2

Clients don’t need to know

- where the distributed object resides

- what operating system it executes on

- how the server object is implemented

clients only know

- the interface its server object publishes

- this interface serves as a building contract between

clients and servers


IDL / 1

it provides no implementation details You can use IDL to define

- API’s concisely- covering important issues such as error handling

IDL-specified methods can be written and invoked from any language- that provides CORBA bindings

Programs deal with CORBA objects- using native language constructs


Marhalling

The process of gathering data and transforming it into a standard format before it is transmitted over a network so that the data can transcend network

boundaries. In order for an object to be moved around a network

it must be converted into a data stream that corresponds with the packet structure of

the network transfer protocol. This conversion is known as data marshalling. Data pieces are collected in a message buffer before they are marshaled. When the data is transmitted, the receiving computer converts the marshaled data back

into an object. Data marshalling is required

when passing the output parameters of a program written in one language as input to a program written in another language.


IDL / 6

C C++ Java Ada COBOL Other

IDL IDLIDLIDLIDLIDL

Client

C C++ Java Ada COBOL Other

IDL IDLIDLIDLIDLIDL

Server

ORB


Structure of CORBA / 3 What exactly is an ORB / 3

ObjectAdapter

DynamicInvocation

DynamicSkeleton

Invocation

StaticSkeletons

ORBInterface

ClientIDL

Stubs

ImplementationRepository

InterfaceRepository

Object Request Broker Core

ClientObject

Implementation


Structure of CORBA / 17Method Invocations / 1

ClientObject

Implementation

ObjectAdapter

DynamicInvocation

ServerIDL

Stubs

ClientIDL

Stubs

Object Request Broker Core

Request


Naming Service / 1

Common Object Services

Naming

Externalization

Persistence

Events

Life Cycle

Transactions

Properties

Query

Concurrency

Relationships

Collections

Time

Security

ChangeManagement

Trader

Licensing

Object Request Broker


CORBA-Strenghts/1

CORBA was designed for integrating applications in heterogeneous environments containing applications written in different

programming languages running on different operating systems and different

machines. CORBA was designed specifically to address

the integration problems faced in a typical IT environment.


CORBA-Strenghts/2

CORBA achieves this level of interoperability by specifying program interfaces in an implementation-neutral

interface definition language (IDL). IDL can be mapped to almost any required programming

language C, C++, FORTRAN, COBOL, Ada, Java,..

allowing you to develop your programs in the language of your choice.

CORBA also specifies the Internet Inter-ORB Protocol (IIOP) as a common communications protocol for TCP/IP networks.

Just as IDL hides programming language differences IIOP enables different applications to communicate with each other

through a standard protocol hiding platform and network differences.


CORBA-Weaknesses/1

There is a lack of products supporting IIOP client side. IIOP don't reach the adoption expected by OMG consortium from the

main software vendors And there are few Programming and administrator software tools

based on CORBA IIOP Loose coupling is a difficult feature in CORBA world:

Client and Server sides are strongly coupled with static and binary IIOP messages it is unfeasible to add some header or information dynamically in

the IIOP messages between the client and the server There is no notion of intermediary node in the CORBA model

even if a distributed object can be in client, server or both roles So loose coupling and agility in the system are difficult or

even unfeasible.


CORBA-Weaknesses/2

IIOP is not firewall friendly and not opened on all firewalls Network administrators have been very reluctant to open ports on

firewalls. If the HTTP protocol has gain lot of facilities to be allowed from the

beginning, it is not the case for IIOP network protocol and CORBA had

suffered this situation. CORBA programming is quite complex

CORBA client programming is somewhere quite complex to master, with complex APIs,

The necessary skills to develop CORBA Clients or CORBA Servers are important, even if the code is always based on template or framework that

can be reused.


CORBA-Competition

Microsoft COM and DCOM Sun Micro System EJB


CORBA-Conclusion

Last CORBA specification releases are from 2002 with the addition of

CORBA 3.0 and CORBA CCM. Currently there are other tendencies in the market

but since there are existing applications running with CORBA they should be considered in order to be integrated.

Efforts on integrating CORBA IDL and Web Services WSDL are on the

roadmap of some of the main CORBA players. This will offer (thanks to idl2wsdl converters) translations from CORBA

description to Web Service description


Application servers/2ORBs/1

- feature varying degrees of complexity

the simplest ones make it possible to connect client applications and distributed objects

make it easy to find and use objects distributed on clients are less well suited for transaction controlled environments

with high data volumes

are called ORBs


Application servers/3ORBs/2

- provide a communication backbone for distributed objects

but normally not the robust infrastructure required to support large numbers of users and mission-critical

operations application developers must access services such as

transaction, persistence, multi-threading on their own


What is a TP monitor ?

TP-monitors are managing programs (or processes) that

operate on data

complex applications are broken into pieces of code

called transactions

Using these transactions, a TP-monitor can get pieces

of software that don’t know anything about each other to

act in total unison


What does a TP Monitor do ? / 1

runs classes of applications that could service

thousands of clients

provides an environment that interjects itself between

the remote clients and servers

manages transactions

routes them across systems


What does a TP Monitor do ? / 2

load balance their execution

restart them after failures

can manage transactional resources on a single server

or across multiple servers

can cooperate with other TP monitors in federated

arrangements


Why a Server Operating System needs a TP Monitor


Distributed Transactions / 1

TransactionContext

Object Request Broker

TransactionalClient Recoverable

Server

BeginEnd

Transaction Service

TransactionalServer

Transactionalmethod propagation involvement


Component transaction monitors

- are application servers that have developed from a mixture of

traditional TP monitors and ORB technologies

- provide infrastructure able to automatically manage

transactions, object distribution, multi-threading, security, persistence, and resources (=Corba services)


Server-side components /2

- Business is always moving, products, processes, and goals of a company are bound to change in the course of times

- If it is possible to encapsulate the software that models a business into a business object, the software will then be flexible, scalable, and reusable and thus be able to develop on its own in line with the business



- A server-side component model defines an architecture for developing distributed business objects

- and combines the accessibility of distributed object systems with the changeability of the business logic in the form of an

object- Server-side component models are used on the application

servers of the middle layer that manage the components at runtime and make them

available to remote clients



- Depending on the component model, the server administrator is able to set the behavior of a server-side component

with respect to transaction, security, and even persistence by assigning certain values to these attributes



- When new products are being developed and corporate processes change

it is possible to re-assemble, change, and extend server-side components in such a way

that the business system will reflect these changes

- A business system can be regarded as a collection of server-side components

that model concepts such as customers, products, reservations, warehouses, etc.



- Each component is like a building block that can be combined with other components to form a business logic

Products can be stored in a warehouse or delivered to a customer

A customer can make a reservation or buy a product

- You can assemble or disassemble components, use them in other components, and change their definitions

- A business system based on server-side components is flexible because it consists of objects, and accessible because the components can be

distributed


Enterprise Bean/1Component

- There are two different types

Entity Bean Session Bean


Enterprise Bean/2Entity Beans

- model business entities that can be expressed in the form of nouns for example: customer, piece of equipment, entry in stock list,

location,...- thus model objects from the real world

persistent data records in some kind of database- represent data and behavior- constitute a system with a reusable and consistent interface to the data

held in a database- behavior typically focuses on applying business rules

directly linked to the modification of data- moreover, Entity Beans may contain relations to other entities- are shared by many clients


Enterprise Bean/3Session Beans/1

- are an extension of the client application and are responsible for managing processes or tasks

for example: they are typically used to manage certain activities such as a reservation; in doing so, they rely on Entity Beans

- All these operations are reflected in the database by actions being performed on the corresponding Entity Beans

- work on behalf of the client and manage operations or tasks- provide the right place for business logic- are not persistent like an Entity Bean

nothing is being mapped onto a database nothing is being saved in between sessions


Sessions Beans/2

- work with Entity Beans, data, and other resources in order to control a business process

- the business process is the key issue in every business system

defines how entities interact with one another in order to model the actual business

- govern tasks and resources but do not themselves represent any data


Sessions Beans/3

- reduce the number of network connections the client needs

improves the system performance- One method call in client applications results in a

multitude of method calls on the server the network registers only the traffic caused by the

one method call for the Session Bean - reduce the number of stubs used on the client side

which in turn saves memory space and CPU time at the client


Stateful Session Beans/1

- manage a conversation state while being used by a client- are not written to the database, but kept in memory

as long as a client uses a session the client can make conversation with the bean while the bean's individual methods are invoked

the state of the Session Bean may change such changes may affect future method calls


Stateful Session Beans/2

- The conversation state remains active only as long as a client actively uses the bean if the client terminates or releases the Session Bean,

the conversation state is lost for ever are bound to a client for their entire lifetime

- manage the state between method calls this is referred to as conversation state

representing the continuous conversation between client and stateful Session Bean

- the integrity of this conversation state must be retrained during the whole time it takes to execute the service

for the client- do not participate in instance pooling- instead an activation is used


Stateless Session Beans

- do not have a conversation state at all- each method is completely independent of all other methods and uses only the data

passed on as parameters- provide the best performance of all bean types

with respect to throughput and use of resources only a few stateless Session Beans are needed

to serve hundreds, or even thousands, of clients- do not manage any state between method calls- each method call is therefore

independent of all others, and executes its task without the use of instance variables

- any stateless Session Bean can serve requests from any EJB object of a suitable type

allows the container to swap bean instances in and out between the client's method calls


Classes and interfaces/1

- In order to implement an Enterprise Bean it is necessary to define two interfaces and one or two classes

Remote interface Home interface Bean class Primary key class


Containers/1

- manages a multitude of interactions between a bean and its server

- is responsible for providing a uniform interface between bean and server

- creates new instances of beans

- ensures that the server stores instances correctly


Resource management and primary services

- How is it possible to manage millions of distributed objects at the same time?

resource management is extremely important how to control

how distributed objects use memory and processing time

- Currently, 6 primary services are supported Multi-threading Transaction management Persistence Object distribution Naming Security


J2EE/1

The J2EE platform (Java 2 Platform, Enterprise Edition) is a software framework that provides technologies for the design and development of multi-tier business applications.

It also provides services that ease the development of business applications, and enable the developer to concentrate

on the business functions he has to implement, not on the technologies involved.


J2EE/2


J2EE/3

The J2EE platform uses a multi-tiered distributed application model. This means application logic is divided into components according to

function and the various application components that make up a J2EE

application are installed on different machines depending on which tier

in the multi-tiered J2EE environment the application

component belongs.


J2EE/4

The J2EE Application parts shown in above figure are presented in

J2EE Application Components

Client tier components run on the client machine

Web tier components run on the J2EE server

Business tier components run on the J2EE server

Enterprise information system (EIS) tier software runs on the EIS

server


J2EE/5

This figure can also be used for representing the architecture of the J2EE platform where the architecture defines a client tier, a middle tier and a back-end tier.

The client tier supports different types of clients from applications and applets to thin web-based and mobile clients.

The middle tier provides infrastructure for the business services and is subdivided into the web tier and the Enterprise JavaBeans (EJB) tier.

The web tier provides services related to the web and thin clients. The EJB tier provides the environment for executing business logic

components. The back-end tier provides enterprise services such as

data persistence but can also host other existing enterprise information systems (EIS).


J2EE/6Strenghts

J2EE works on any platform with a compliant Java VM and a compliant set of required platform services

EJB container, JMS service, etc., etc.. All of the specifications that define the J2EE platform are published and

reviewed publicly and numerous vendors offer compliant products and development

environments. The different J2EE integration technologies can be used in different

integration problems


J2EE/7Weakness

There's a gap between J2EE's strength in designing applications and the need to manage the composite nature of newer programs

that have real-time requirement you will need to use Integrated transactions, message

routing, integrity, wrappers, bridges and access tools to external applications, etc.

J2EE is a single-language platform. Calls from/to objects in other languages are possible through

CORBA but CORBA support is not a ubiquitous part of the platform


J2EE/8Competitors

Main competitor is Microsoft .Net platform

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 1 dr. withalm 7-sep-15

Documents