SOA Part1 Lecture 1

1. SOA Part1 Lecture 1 Dr. Withalm 4-Jan-20

2. Lectures at the University of Bratislava/Autumn 2017 03.10.2017 Lecture 1 The long Way from OO to SOA & WEB- Services 17.10.2017 Lecture 2 Semantic WEB & SOA-Technological Basis 14.11.2017 Lecture 3 SOA-Basing on J2EE & SOA-Focus on Business Processes 21.11.2017 Lecture 4 B2B Frameworks and related Standards 28.11.2017 Lecture 5 WEB 2.0 & GRID & Cloud Computing Dr.Withalm

3. Today’s Agenda • Software Architecture • Programming Paradigm • CORBA • Application Server • TP Monitor • EJB • J2EE • WEB Services • Example • Standards Dr.Withalm

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

5. 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 Dr.Withalm

6. 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. Dr.Withalm

7. 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. Dr.Withalm

8. 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. Dr.Withalm

9. 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.) Dr.Withalm

10. Web Server Print Server Directory Server Database Server File Server Mail Server Client-Server (cont.) Dr.Withalm

11. 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 peernodes 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. Dr.Withalm

12. 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. User Interface Tier Application Tier Data Tier Dr.Withalm

13. N-Tier Model User Interface Tier Data Tier Application Tier Dr.Withalm

14. Wire together to build a small device Put together to build a complex device Service Consumer Back Office Service Archiving Service Print Service 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. Dr.Withalm Archiving Service

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

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

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

18. 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. Dr.Withalm

19. C++ C++ C C Ada Ada Other Other COBOL COBOL IDL IDL IDL IDL IDL IDL IDL IDL IDL IDL IDL IDL Java Java IDL / 6 Client Server ORB Dr.Withalm

20. Client Object Implementation Interface Repository Implementation Repository Dynamic Invocation Client IDL Stubs ORB Interface Static Skeletons Dynamic Skeleton Invocation Object Adapter Object Request Broker Core Structure of CORBA / 3 What exactly is an ORB / 3 Dr.Withalm

21. Object Implementation Client Dynamic Invocation Client IDL Stubs Server IDL Stubs Object Adapter Request Object Request Broker Core Structure of CORBA / 17Method Invocations / 1 Dr.Withalm

22. Object Request Broker Common Object Services Naming Persistence Life Cycle Properties Concurrency Collections Security Trader Externalization Events Transactions Query Relationships Time Change Management Licensing Naming Service / 1 Dr.Withalm

23. 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. Dr.Withalm

24. 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. Dr.Withalm

25. 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. Dr.Withalm

26. 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. Dr.Withalm

27. CORBA-Competition • Microsoft COM and DCOM • Sun Micro System EJB Dr.Withalm

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

29. 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 Dr.Withalm

30. 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 Dr.Withalm

31. 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 Dr.Withalm

32. 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 Dr.Withalm

33. 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 Dr.Withalm

34. Why a Server Operating System needs a TP Monitor Dr.Withalm

35. Transactional Client Transactional Server Recoverable Server Begin End Transactional method propagation involvement Object Request Broker Transaction Context Transaction Service Distributed Transactions / 1 Dr.Withalm

36. 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) Dr.Withalm

37. 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 Dr.Withalm

38. Server-side components /3 - 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 Dr.Withalm

39. Server-side components /5 - 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 Dr.Withalm

40. Server-side components /6 - 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. Dr.Withalm

41. Server-side components /7 - 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 Dr.Withalm

42. Enterprise Bean/1Component - There are two different types • Entity Bean • Session Bean Dr.Withalm

43. 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 Dr.Withalm

44. 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 Dr.Withalm

45. 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 Dr.Withalm

46. 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 Dr.Withalm

47. 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 Dr.Withalm

48. 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 Dr.Withalm

49. 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 Dr.Withalm

50. 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 Dr.Withalm