Chapter 2 Technologies for Ecommerce v Ecommerce Models

Chapter 2

Technologies for E-commerce v E-commerce Models v The Internet v. Distributed Computing v. Summary

v E-commerce Models q. Business-to-Business Electronic Data Interchange (EDI) Just-in-time (JIT) Commercial Auction q. Business-to-Consumer Online Shopping Cart Online Banking Person-to-person Auction

ØBusiness-to-Business • Factors – Just-In-Time Delivery Requirement • Reduce Inventory, Cycle Times • Reduced Costs – International Trade (Globalization, Deregulation) – Move to Automated Transactions – Developing Trust • With New Partners • Contract Protocols: Formal, Creative – Low-Cost, Secure Large Transactions – Sharing Minimum Required Operational Information

Electronic Data Interchange (EDI) • What is EDI? – Electronic Data Interchange, or EDI, is the computer-to-computer exchange of business documents using a standard format – a method of transmitting business data from one computer to another, without the need to re-key data • Without normalization 4 companies – 12 formats for the same message

q. What is EDI – Normalized language EDIFACT normalization is part of the UNO missions EDIFACT EDITEXT EDISPORT INOVERT Orders EFOVAD EANCOM Despatch Advice ODETTE Invoice Transport Automobile Retail

q. Benefits of EDI Improves the speed of information exchanged between companies Reduces operational costs Minimized potential for error Confirmation on the exchange of documents Minimized paper use and storage

Just-in-time (JIT) • Try to reduce the system operational inefficiencies and the resulting waste by identifying the sources of these inefficiencies and working proactively to eliminate them as much as possible. • In the emerging philosophy, inventories should be carefully controlled and they should not function as the mechanism for accommodating the system inefficiencies => Just-In-Time (JIT) • The aforementioned effort should be an ongoing process towards continuous improvement rather than one-time/shot effort.

Just-in-time (JIT) The financial benefits of JIT production are: • Lower investment in inventories. • Reduction in carrying and handling costs of inventories. • Lower investment in plant space for inventories and production. • Reduction in set-up time and total manufacturing costs. • Reduction in wastes and spoilage. • Higher revenues as a result of faster response to customers.

q Online Banking • Why is it Important – For Customers: – There’s a seemingly receptive audience out there waiting – Most don’t feel the need to have a face-to-face conversation with tellers or think its important to have a checking account with a local branch office. – For Banks: – – The most important reason being ECONOMICS. Each Internet transaction typically costs the bank one cent Compare that with 27 cents for each ATM transaction USD 1. 07 every time you go up to a tellers window !!!

Online Banking

v The Internet q. Brief Introduction to the Internet q. World Wide Web q. Common Gateway Interface (CGI) Perl C++ q. Server Side Include (SSI) ASP PHP q. Client Side Include (CSI) Java Script Visual Basic Script

q. Brief Introduction to the Internet -The Word Internet comes from the term internetwork, which means “to communicate between networks”. -The Internet’s naming convention is stated in the Domain Name Service (DNS). A DNS name has the following format: subdomain. […]. domain

q. Brief Introduction to the Internet (cont…) - The distributed database and software that make up the DNS name resolution system is comprised of the following basic parts: § Domain name space § Name servers § Resolvers

q. Name Servers Part of the DNS name space showing the division into zones.

q. World Wide Web - The client sends the following text to the server: GET /docu 2. html HTTP/1. 0 Accept: www/source Accept: text/html Accept: image/gif User-Agent: Lynux/2. 8. 1 libwww/2. 14 From: A@www. fsktm. um. edu. my * a blank line *

q. World Wide Web - The server responds by sending: HTTP / 1. 0 200 OK Date: Wednesday, 30 -September-00 23: 04: 12 GMT Server: NCSA / 1. 1 MIME-version: 1. 0 Content-type: text/html * a blank line * <HTML><HEAD><TITLE>…………</TITLE>………etc.

q. World Wide Web The steps that occur between the user’s click and the page being displayed are as follows: 1. The browser determines the URL (by seeing what was selected) 2. The browser asks DNS for the IP address of www. w 3. org. 3. DNS replies 18. 23. 0. 23. 4. The browser makes a TCP connection to port 80 on 18. 23. 0. 23. 5. It then sends a GET /hypertext/topics. html command. 6. The www. w 3. org server sends the file topics. html 7. The TCP connection is released. 8. The browser displays all the text in topics. html. 9. The browser fetches and displays all images in topics. html.

q. Server-Side Include (SSI) ASP <@ LANGUAGE=“VBSCRIPT” %> <HTML> <TITLE>My First ASP!</TITLE> <BODY> <CENTER>Hello World ASP! <BR> <% Response. Write(“Hello World for ASP!”) %><BR> All done! <CENTER> </BODY> </HTML>

q. Server-Side Include (SSI) (cont…) PHP <html> <head> <title>My Sample Page</title> </head><body> <? php $greeting “Hello World”; echo $greeting; ? > </body> </html>

v Distributed Computing To develop a framework for the programmers design and implement new applications for heterogeneous distributed environment different interest groups produce different distributed computing frameworks. Example: q Distributed Computing Environment (DCE) by OSF Foundation) q Distributed Component Object Model (DCOM) by Microsoft q Common Object Request Broker Architecture (CORBA) by OMG q Remote Method Invocation (RMI) by Sun Microsystem

Introduction to Middleware I • What is Middleware? – Layer between OS and distributed applications – Hides complexity and heterogeneity of distributed system – Bridges gap between low-level OS commands and programming language abstractions – Provides common programming abstraction and infrastructure for distributed applications Distributed. Applications Distributed Applications Middleware Operating. System. Comms Operating System Comms Network (remote calls, object invocation, messages, …) (sockets, IP, TCP, UDP, …) (packets, bits…)

Introduction to Middleware II • Middleware provides support for (some of): – – Naming, Location, Service discovery, Replication Protocol handling, Communication faults, Qo. S Synchronisation, Concurrency, Transactions, Storage Access control, Authentication • Middleware dimensions: – – – Request/Reply Language-specific Proprietary Small-scale Tightly-coupled vs. vs. vs. Asynchronous Messaging Language-independent Standards-based Large-scale Loosely-coupled components

q. Distributed Computing Environment (DCE) -The Components that constitute the DCE RPC are as follows: 1. 2. 3. 4. 5. 6. 7. IDL and the IDL compiler The RPC runtime library Authenticated RPC Name Service Independent (NSI) API DCE host daemon DCE control program UUID facilities DCE Provide Services: • DCE Directory Service • DCE Distributed File Service (DFS) • DCE Distributed Time Service (DTS) • DCE Security Service

Outline • Part I: Remote Procedure Call (RPC) – Historic interest • Part II: Object-Oriented Middleware (OOM) – Java RMI – CORBA – Reflective Middleware arc e res h • Part III: Message-Oriented Middleware (MOM) – Java Message Service – IBM MQSeries – Web Services • Part IV: Event-Based Middleware – Cambridge Event Architecture – Hermes rch a e s e r

The two models of accessing a component Application • • Multiply • Divide • Square Root Calculator In-process model • Multiply • Divide • Square Root Application • Calculator Network Out-of-process model

Principle of Remote Procedure Call (RPC) Conceptually Caller 1 Stub Callee Reality 3 2 Skeleton Network 1. marshalling; 2. transporting; 3. unmarshalling

Distributed COM (DCOM) Conceptually App 1 Stub COM Obj Reality 3 2 Network Skeleton

Remote Procedure Call (RPC) • Masks remote function calls as being local • Client/server model • Request/reply paradigm usually implemented with message passing in RPC service • Marshalling of function parameters and return value Caller call(…) RPC Service 1) Marshal args 2) Generate ID 3) Start timer 8) Unmarshal 9) Acknowledge RPC Service message 4) Unmarshal 5) Record ID 6) Marshal 7) Set timer Remote Function fun(…)

Properties of RPC ü Language-level pattern of function call • easy to understand for programmer ü Synchronous request/reply interaction • natural from a programming language point-of-view • matches replies to requests • built in synchronisation ü Distribution transparency (no-failure case) • hides the complexity of a distributed system ü Various reliability guarantees • deals with some distributed systems aspects of failure

Failure Modes of RPC • Invocation semantics supported by RPC in the light of: network and/or server congestion, client, network and/or server failure note DS independent failure modes • RPC systems differ, many examples, local was Mayflower Maybe or at most once (RPC system tries once) • Error return – programmer may retry Exactly once (RPC system retries a few times) • Hard error return – some failure most likely note that “exactly once” cannot be guaranteed

Disadvantages of RPC Ò Synchronous request/reply interaction • tight coupling between client and server • may block for a long time • leads to multi-threaded programming fork(…) Ó Distribution Transparency remote call • Not possible to mask all problems Ó Lacks notion of services join(…) • programmer not interested in server but in service Ó RPC paradigm is not object-oriented • invoke functions on servers as opposed to methods on objects

Object-Oriented Middleware (OOM) • • • Objects can be local or remote Object references can be local or remote Remote objects have visible remote interfaces Masks remote objects as being local using proxy objects Remote method invocation local object A proxy object B OOM object request broker / object manager remote skeleton object B

Properties of OOM ü Support for object-oriented programming model • objects, methods, interfaces, encapsulation, … • exceptions (also in some RPC systems e. g. Mayflower) ü Location Transparency • mapping object references to locations ü Synchronous request/reply interaction • same as RPC ü Services

The Goal of RMI • To extend the Java Object model to support programming with distributed Objects • The intention is to make distributed programming as easy as standard Java programming – Focus on application logic not distribution 35

RMI: Remote Method Invocation RMI Registry 1 RMI Service Object 2 3 Client

A Simple Overview • Java RMI allows one Java object to call methods on another Java object in a different JVM Client JVM Method parameters Local Object Remote Object Result or exception Server JVM 37

Lookup in Java RMI Interface Remote Object Client Program Server Program naming. lookup(“rmi: //localhost: 1099/ Test. Service”) naming. rebind(“rmi: //localhost: 1099/Test. S ervice”, Remote. Object. Reference) Server Client RMIRegistry 38

The RMI Architecture 39

Stubs and Skeleton Layer • Stubs and skeletons are generated from the remote interface – Using the “rmic” Java tool Interface Client Stub Server Skel • Stub communicates with a skeleton rather than the remote object – This a Proxy approach – Marshalls the parameters and results to be sent across the wire – After java 1. 1 skeletons were made obsolete and RMI now uses reflection to direct a request to an object 40

Parameter Passing • Parameter Passing in Java RMI is different from standard Java – Reminder: In Java, primitives are passed by value, Objects are passed by reference • In Java RMI – Objects and primitives are passed by value – Remote objects are passed by reference • You must be aware of the differences! – Otherwise you'll generate logical bugs that are difficult to identify 41

Parameter Passing (2) • RMI-Pass by Value – All ordinary objects and primitives are serialised and a copy is passed – Any changes to the copy do not affect the original – It is your job to ensure your Objects can be serialised! • RMI-Pass by Reference – Remote Object is the parameter, a stub (reference) is sent – the stub is used to modify the object, the original object is modified 42

RMI • Protocol: Java Remote Method Protocol (JRMP) on the top of TCP/IP • RMI Server: – Define an interface – Expose a set of methods • RMI Client: – Lookup a server object reference in RMIRegistry – Invoke methods in the server object • RMI Registry – Holds information about available server objects – Naming mechanism: URL

RMI is not a component model • RMI is more a communication standard than a component model • Java component models which are built on RMI – Java Embedded Server – Java Dynamic Management Kit – Info. Bus – Java. Bean Activation Framework – Enterprise Java. Bean

Java Remote Method Invocation (RMI) • Covered in 1 B Concurrent Systems • Distributed objects in Java public interface Print. Server extends Remote { int print(Vector print. Job) throws Remote. Exception; } • RMI compiler creates proxies and skeletons • RMI registry used for interface lookup • All system written in Java (single-language system)

Component Object Model • How should one chunk of software access the services provided by another chunk of software? • COM: A standard approach to access all kinds of software services, regardless of how they are provided • COM is transforming the way software is constructed • Benefits of COM – Offers the benefits of object orientation – Provides consistency – Is language independent • COM defines a binary interface that objects must support – Simple and efficient versioning – Available on Windows, Windows NT, Macintosh, MVS up to now – DCOM allows COM objects on all kinds of systems to interact

Communications between Software lib Application OS

Basic COM Concept Interface Binary Code of a Client Class COM Library Interface Binary Code of a Server Class

Basic COM Concept Interface COM object Interface Server

Basic COM Concept COM object Client

Basic COM Concept Application lib Application OS OS Application

Accessing a COM Object in an In. Process Server Client Object Client process

Accessing a COM Object in a Local Server Client Proxy Stub Object Server Process Client process Single machine

Accessing a COM object in a Remote Server Proxy Client process Machine X Stub Object Server Process Machine Y

Distributed Component Object Model (DCOM) • Designed by Microsoft • Based on Component Object Model (COM) • Addresses issues such as: – Interoperability • Different applications, platforms, languages – Versioning • Compatibility between a new version of a server and old versions of clients – New interfaces should preserve the old interface – Naming • Use Globally unique identifiers

History • DDE OLE 1 COM OLE DCOM • Dynamic Data Exchange (DDE) – For data exchange between any application through clipboard package – Originally for Windows 2. 1 • Object Linking and Embedding (OLE v 1. 0) – – A compound document can embed objects belonging to other applications E. g. , an Excel spreadsheet in a Word document An embedded object is linked to its original application Restricted to document objects

History (continued) • Component Object Model (COM) – Interoperability of components – Ability to share non-document based components – Object-based technology • Identity, polymorphism (multiple interfaces to a component), interface inheritance • OLE – Layered on top of COM (and DCOM) – Links the application layer to the underlying COM architecture

Object Model • The difference between language-defined (CORBA) and binary interfaces (DCOM)

DCOM Properties • Distributed shared memory management – DCOM provides interfaces for distributed components to share memory • Network interoperability and transparency • Dynamic loading and unloading – DCOM manages reference counts to objects – Unloads objects whose reference count is 0 • Status reporting – Of remote execution using HRESULT struct

DCOM Services • DCOM is responsible for initializing a connection between components, and – Negotiating protocols for communication • DCOM provides support for persistent storage – Objects can persist • Components can be assigned “intelligent names” called monikers

q. Distributed Component Object Model (DCOM)

DCOM Architecture • SCM: Service Control Manager

Creating objects • Classes of objects have globally unique identifiers (GUIDs) – 128 bit numbers – Also called class ids (CLSID) • DCOM provides functions to create objects given a server name and a class id – The SCM on the client connects to the SCM of the server and requests creation of the object

MIDL • An extension of DCE’s IDL • The MIDL compiler generates the client and server stub files • Every DCOM interface inherits from an interface known as IUnknown – Interface names start with I – IUnknown has three methods • Add. Ref(), Release() and Query. Interface() • Add. Ref() and Release() are used to manage reference counts (for memory management)

Events • Event processing in DCOM.

Passing an Object Reference in DCOM (with custom marshaling)

Monikers • Object names (as opposed to class names) are called monikers • A moniker distinguishes one instance from another of the same class • Monikers themselves are objects • Each moniker has its own persistent data, which contains everything the moniker needs to start and initialize the single object instance the moniker identifies • When a client passes a moniker to access an object, COM looks up a Running Object Table (ROT) for the moniker name – If it exists, a pointer to the object is returned – Else, a new object instance is created, its state is restored, its reference is entered in ROT, and a pointer to the object is returned to the client • Monikers contain reference to the object’s persisted state

Why We Need CORBA? Need a solution to develop, deploy, and integrate systems in a distributed heterogeneous environment. • Diverse OS – Unix, Windows, Mac. OS etc. • Diverse Network – TCP/IP, Ethernet, ATM, etc. • Diverse Programming Language – applications programmed in C++, JAVA, COBOL etc. • Diverse Hardware Platform. • Coexist with legacy systems.

What is CORBA? CORBA – Common Object Request Broker Architecture Middleware that provides the necessary framework and API for developing distributed applications Main Components of CORBA üORB Core üCORBA Objects üOMG Interface Definition Language (OMG IDL) üStubs and Skeletons üDynamic Invocation Interface, Dynamic Skeleton Interface üObject Adapter (Portable Object Adapter) üInterface Repository üORB Interoperability

Introduction to CORBA Ø What is CORBA? Ø A system providing interoperability between objects in a distributed environment Ø Specification of a standard architecture for object request brokers (ORBs) Ø OMG’s open, vendor-independent architecture Ø Middleware to help development of distributed object systems. Ø What does CORBA do? Ø Provides interoperability among corba-based programs independent of ü ü ü vendor programing language computer(hardware) operating system network

The OMG • The Object Management Group (OMG) was formed in 1989. Its aims were: – to make better use of distributed systems – to use object-oriented programming – to allow objects in different programming languages to communicate with one another • The object request broker (ORB) enables clients to invoke methods in a remote object • Developed by the OMG (Object Management Group) – A consortium of over 700 companies. – Goal - to develop, adopt, and promote standards for the development and deployment of applications in distributed heterogeneous environments. § Incompatibility between compilers § Differences in object models § Differences in platforms § Solution: CORBA •

CORBA Ø Where is CORBA used? Ø Ø Servers handling large number of clients Mainframes Websites Embedded real time system Ø How does CORBA work? Ø CORBA applications are composed of objects Ø For each object type, an interface in IDL(interface definition language) is defined Ø Clients use this IDL interface to invoke an operation on the object Ø The same interface is used on the object side to perform the requested operation Ø The interface definition is then used to direct the results to their trip back till they reach their destination Ø The IDL (interface definition language) is independent of programming language but maps to all of the popular programming languages. Ø For remote invocations, the client's ORB and object's ORB must agree on a common protocol – IIOP( Internet Inter-ORB Protocol)

Characteristics of CORBA Ø Interoperability Ø Seperates interface from implementation by IDL Ø Encapsulation: The data and the running code in the object is hidden from the rest of the system by the strict interface Ø Location transparency : The ORB can tell from the object reference that the target object is remote, the client can not.

CORBA • Common Object Request Broker Architecture. – Open standard – 1991 – version 1. 0 • Initial version. – 1995 – version 2. 0 • IIOP • OMA • More languages support – 2002 – version 3. 0 • Corba Component Model (CCM) • Scripting languages support

Generic Architecture Client Server Object Middleware

CORBA Architecture • Remote-object: object implementation resides in server’s address space Client Server Java Object C++ Object Skeleton Stub Object Adapter ORB

Stub • Provides interface between client object and ORB • Marshalling: client invocation • Unmarshalling: server response Client Server Java Object C++ Object Skeleton Stub Object Adapter ORB

Skeleton • Provides iterface between server object and ORB • Unmarshaling: client invocation • Marshaling: server response Client Server Java Object C++ Object Skeleton Stub Object Adapter ORB

(Portable) Object Adapter (POA) • • Register class implementations Creates and destroys objects Handles method invokation Handles client authentication and access control Client Server Java Object C++ Object Skeleton Stub Object Adapter ORB

Object Request Broker (ORB) • Communication infrastructure sending messages between objects • Communication type: – GIOP (General Inter-ORB Protocol) – IIOP (Internet Inter-ORB Protocol) (GIOP on TCP/IP) Server Client Java Object C++ Object Skeleton Stub ORB IIOP Object Adapter ORB

CORBA Object Server CORBA Object Interoperable Object Reference Interface IDL C++/Java Implementation Servant

IDL • Interface Definition Language – – – Defines all object interfaces in a common language Bindings are available for C, C++, Java, Python, Smalltalk, Cobol, etc… An IDL compiler generates stubs and skeletons. • • Stubs: – Looks like local object – Marhals arguments – Forwards all invocations through ORB to target object Skeletons: – Receives invocations from ORB – Unmarshals arguments – Invokes target methods – Sends back return value

Interface Definition Language (IDL) • Describes interface • Language independent • Client and server platform independent Server CORBA Object Interoperable Object Reference Interface IDL C++/Java Implementation Servant

Overall CORBA Architecture Client C++ Object Implementation Interface repository IDL Server Java Object Interface repository the interface repository provides information about registered IDL interfaces to Skeleton clients and servers that require it. Stub Object Adapter Implementation repository IIOPon demand locates running servers wactivates registered servers ORB wuses the object adapter name to register and activate servers

CORBA and OMG IDL source Applications Programs Dynamic invocation interface IDL stubs IDL compiler ORB interface Object Request Broker (ORB) Object servants IDL Skeletons Dynamic Skeleton interface Object Adapter

Example of CORBA Services • Naming: Keeps track of association between object names and their reference. Allows ORB to locate referenced objects • Life Cycle: Handles the creation, copying, moving, and deletion objects • Trader: A “yellow pages” for objects. Lets you find them by the services they provide • Event: Facilitates asynchronous communications through events • Concurrency: Manages locks so objects can share resources • Query: Locates objects by specified search criteria…

Object Invocation Models • Invocation models supported in CORBA Request type Failure semantics Description Synchronous At-most-once Caller blocks until a response is returned or an exception is raised One-way Best effort delivery Caller continues immediately without waiting for any response from the server Deferred synchronous At-most-once Caller continues immediately and can later block until response is delivered

Security • Transparency: application-level objects should be unaware of security services which are used • Control: client/object should be able to specify security requirements • Security polices: specified by policy objects • Administrative domain where client/server is executed determines set of security services

Secure Object Invocation in CORBA

CORBA Application 1) 2) 3) 4) Define interface using IDL Compile interface Implement interface Instantiate server: • Register object as a CORBA object 5) Instantiate client: • • Invoke CORBA object Example using a Java client and server

CORBA Services (selection) • Naming Service – Names remote object references • Trading Service – Attributes (properties) remote object references • Persistent Object Service – Implementation of persistent CORBA objects • Transaction Service – Making object invocation part of transactions • Event Service and Notification Service – Asynchronous communication based on messaging (cf. MOM), not integrated programming model with general IDL messages

CORBA vs. DCOM (1) Issue CORBA DCOM Design goals Interoperability Functionality Object model Remote objects Services Many of its own From environment Interfaces IDL based Binary Sync. communication Yes Async. communication Yes Callbacks Yes Events Yes Messaging Yes Object server Flexible (POA) Hard-coded Directory service Yes Trading service yes No

CORBA vs. DCOM (2) Issue CORBA DCOM Naming service Yes Location service No No Object reference Object's location Interface pointer Synchronization Transactions Replication support Separate server None Transactions Yes Fault tolerance By replication By transactions Recovery support Yes By transactions Security Various mechanisms

Disadvantages of OOM ÓSynchronous request/reply interaction only • So CORBA oneway semantics added and • Asynchronous Method Invocation (AMI) • But implementations may not be loosely coupled ÓDistributed garbage collection • Releasing memory for unused remote objects ÓOOM rather static and heavy-weight • Bad for ubiquitous systems and embedded devices

Message-Oriented Middleware (MOM) • • Communication using messages Messages stored in message queues Optional message server decouples client and server Various assumptions about message content Client App. Server App. Message Server local message queues Network

Properties of MOM ü Asynchronous interaction – Client and server are only loosely coupled – Messages are queued – Good for application integration ü Support for reliable delivery service – Keep queues in persistent storage ü Processing of messages by intermediate message server – Filtering, transforming, logging, … – Networks of message servers ü Natural for database integration

Java Message Service (JMS) • API specification to access MOM implementations • Two modes of operation specified: – Point-to-point • One-to-one communication using queues – Publish/Subscribe • cf. Event-Based Middleware • JMS Server implements JMS API • JMS Clients connect to JMS servers • Java objects can be serialised to JMS messages

Disadvantages of MOM Ó Poor programming abstraction (but has evolved) • Rather low-level (cf. Packets) • Request/reply more difficult to achieve • Results in multi-threaded code Ó Message formats unknown to middleware • No type checking (JMS addresses this – implementation? ) Ó Queue abstraction only gives one-to-one communication • Limits scalability (JMS pub/sub – implementation? )

q. Distributed Computing Environment (DCE) -The Components that constitute the DCE RPC are as follows: 1. IDL and the IDL compiler 2. The RPC runtime library 3. Authenticated RPC 4. Name Service Independent (NSI) API 5. DCE host daemon 6. DCE control program 7. UUID facilities

q. Common Object Request Broker Architecture (CORBA)

q. Remote Method Invocation (RMI)

Thank you