1. Component-Based Software Engineering Introducing the Bank Example Paul Krause

2. Lecture 4 - Contents  Basic Structure of RMI  Introducing the Bank Example  Core architecture of the Bank Example

3. Basic Structure of RMI  The useful stuff - “Business Logic”  UI code for the client  Some code to exchange information between client and server  Code to launch and configure the application  Some code to make the application more robust and scalable

4. Basic Structure of RMI  The useful stuff - “Business Logic”  UI code for the client  Some code to exchange information between client and server  Code to launch and configure the application  Some code to make the application more robust and scalable

5. “Marshalling” Data  Marshalling: A client takes a service request and puts it into a format (including arguments and data) suitable for sending over a socket connection A client takes a service request and puts it into a format (including arguments and data) suitable for sending over a socket connection  Demarshalling: The process by which the server reconstructs the service request The process by which the server reconstructs the service request  See also “serialization”

6. Basic RMI Process  Client obtains a stub class  Client calls a method in the stub  Stub creates a socket connection to the (skeleton on the) server Marshalls method name and arguments and sends to the skeleton Marshalls method name and arguments and sends to the skeleton  Skeleton demarshalls data and makes the method call on the server

7. Returning an RMI call  Skeleton gets return value from the server  Skeleton marshalls the return data and sends it to the stub  Stub demarshalls the return value and returns it (“as if” it was a local method call) to the client

8. Overview of RMI Client Server Network Stub: Marshalls invocation and sends data over to the skeleton Skeleton: Demarshalls data and invokes method on server

9. Introducing the Bank Example When travelling, take advantage of more than 13,000 Bank of America ATMs coast to coast. We’re in 30 states and the District of Columbia. As a Bank of America Check Card (sic) or ATM cardholder, there’s no ATM fee when you use an ATM displaying a Bank of America sign … - Bank of America advert (of some vintage)

10. Basic Distributed Architecture  Server Centralised on a small set of machines. Centralised on a small set of machines. Long running with important data Long running with important data All the business logic resides in the server All the business logic resides in the server  Client Short lived program Short lived program Persistent state resides in server Persistent state resides in server Makes few demands on client machine Makes few demands on client machine

11. Sketching the Architecture  What are you going to build?  Find a basic use case sometimes more than one sometimes more than one  What can you ignore Priorities, risks Priorities, risks  Physical constraints Deployment environment Deployment environment  Narrow down servers to core choices

12. Basic Use Case  User enters ID card  User enters password  If password correct, user can perform a transaction  User has a menu of choices for actions  User may choose account(s) for a specific action  After performing the transaction, the user leaves (taking the card with them)

13. Key Assumptions  There will be a server (or servers - we will discuss this!) written in Java  The server will be registered with a naming service (we’re going to have to discuss this too!)  The client (also written in Java) will connect to the naming service, retrieve a stub for the service, and use the stub to connect with the server

14. Design Postponements  Security We won’t talk about this much We won’t talk about this much  Scalability This is interesting! This is interesting!

15. Basic Architecture Database System Client Server Registry

16. Inventory of Components  Client  Stub  Registry  Skeleton and launch code  Servers  Database system

17. Client  Responsible for handling the interaction with a user  Obtains stub to the server from the registry and then invokes methods on the server

18. Stub  Implicitly, and without client knowledge, handles details of the Secure socket layer Secure socket layer  Connection

19. Registry  Maintains a mapping of human-readable names to server stubs  Responds to queries by returning serialized copies of stubs

20. Skeleton and launch code  To be discussed later!

21. Servers  These handle the “business logic”  They must: Respond to client requests Respond to client requests Manipulate data Manipulate data Store the data out to a database Store the data out to a database

22. Database system  Responsible for Long term persistence Long term persistence Integrity of data Integrity of data

23. Key questions?  How many servers?  What are they?

24. Key Problems  Partial Failures  Network Latency