Distributed Object

Three-Tier C/S Architecture and Middleware

∙Two-tier C/S system

- Direct m×n connections between clients and servers

- Application: Data Mgmt. + Appl. Logic + Presentation

□Remote Data Mgmt: Applet

□Distributed Function: C/S program, stored procedure

□Remote Presentaion: CGI, Servlet

∙Three-Tier Client/Server Architecture

- In the middle of the database server and the user interface client

⇒ The separate 'application logic' component has connection between presentation and data management.

Presentation 1

Presentation m

Appl. Logic 1

Appl. Logic k

…

…

Middleware

User 1

Client

Appl. Server

User m

Data Mgmt 1

DB 1

DB n

…

Data Mgmt n

DB Server

- Manage the problems caused by direct m×n connections between clients and servers in two-tier C/S architecture.

⇒ Middleware

⇒ 'Scalibility' and 'extensibility' of application S/W

Ex)

Browser

Browser

Servlet 1

Servlet m

…

…

CORBA ORB

User 1

Client

Appl. Server

User m

Remote Obj 1

DB 1

DB n

…

Remote Obj n

DB Server

HTTP

IIOP

JDBC/NET8

Web Server

TCP/IP

Wired/Wireless Network

callback

callback

∙Middleware

- Applications for the three-tier C/S architecture are built on middleware.

- Deals with problems caused by multiple servers and a large no. of clients

⇒ Supports network transparency, load balancing and system flexibility

- Three types of Middleware

① Database Access

- Provides uniform access to heterogeneous DBMSs.

- ODBC(MS), IDAPI(Borland), CLI(SAG), Glue(Oracle)

② TP Monitor

- Provides an application server with distributed transaction processing

- X/Open, Tuxedo, Encina

③ (Distributed) Object Request Broker

- Provides access to remote objects.

- DCE(OSF), JavaBeans(Sun), CORBA(OMG), DCOM(MS)

⇒ Enterprise JavaBeans (EJB): ②+③

⇒ Component Transaction Monitors (CTM)

TP Monitor

∙Provide the core support for distributed transaction processing.

⇒ ACID properties on distributed DBs.

∙History

- Developed in the 70s and 80s.

Ex) CICS(IBM), Pathway(Tandem), Tuxedo(NCR), Encina(Transac)

∙Architectures

Ex) p.673 Fig. 20.2

(Distributed) Object Request Broker

∙Services

Ex) CORBAServices

□Collection: Provides access to a variety of data structures.

□Concurrency Control: Enables multiple clients to coordinate access to 'shared' resources.

□Event: Enables 'events' to be delivered from multiple event sources to multiple event listeners.

□Externalization: Enables an object (or objects) or a graph to be written out a stream of bytes.

⇒ Object serialization in JDK.

□Licensing: Allows contents authors to ensure that their efforts are not being used by others for profit.

□Life Cycle: Defines conventions for creating, deleting, copying, and moving objects.

□Naming: Allows objects to be tagged with a 'unique' logical name.

⇒ This service can be told of the 'existence' of objects and can also be 'queried' for registered objects.

□Persistent Object: Enables objects to be stored in some medium.

⇒ The medium will usually a 'relational' or 'object' database, but could be virtually anything.

□Property: Enables name/value pairs to be associated with an object.

Ex) Some image file could be tagged with name/value pairs describing its content.

□Query: Enables queries to be performed against collections of objects.

□Relationship: Enables the relationship bet. entities to be logically represented.

□Security: Enables access to objects to be restricted by user or by role.

□Time: Enables to obtain the current time along with the margin of error.

(t±ㅿt)

□Trader Object: Allows objects to locate certain services by functionality.

⇒ The object will first discuss with the trader service whether a particular service is available; then it negotiates access to those resources.

□Transaction: Manages multiple, simultaneous transactions in distributed environment.

⇒ CORBAservices are always developed by the OMG.

⇒ A few more services will be added.

∙Architecture

- The 'skeleton' and 'stub' provide the services (connection etc.).

Client

Object

Client

JVM

Remote

Object

Server

JVM

Stub

Skeleton

Interface

Interface

Ex) Simplified example codes

① Interface: PersonInter.java

public interface PersonInter{

public String getName() throws Throwable;

public int getAge() throws Throwable;

}

Data class: Person.java

public class Person implements PersonInter{

String name;

int age;

public Person(String name, int age){

this.name = name;

this.age = age;

}

public String getName(){

return name;

}

public int getAge(){

return age;

}

}

② Server: PersonServer.java

public class PersonServer{

public static void main(String args[]){

Person person;

Person_Skel skel;

try{

person = new Person("David", 12);

skel = new Person_Skel(person);

skel.start();	// skel is a thread...

}catch(Exception e){

e.printStackTrace();

}

}

}

③ Skeleton: Person_Skel.java

import java.io.ObjectOutputStream;

import java.io.ObjectInputStream;

import java.net.Socket;

import java.net.ServerSocket;

public class Person_Skel extends Thread{

Person myperson;

ServerSocket serversocket;

Socket socket;

static final int PORT_NO = 9000;

String remotemethod;

public Person_Skel(Person person){

this.myperson = person;

}

public void run(){

try{

serversocket = new ServerSocket(PORT_NO);

socket = serversocket.accept();

while(socket!=null){

// Receive the remote method name from the stub...

ObjectInputStream instream

= new ObjectInputStream(socket.getInputStream());

remotemethod = (String)instream.readObject();

// Invoke the method on the server object and send the result...

if (remotemethod.equals("name")){

ObjectOutputStream outstream

= new ObjectOutputStream(socket.getOutputStream());

outstream.writeObject(myperson.getName());

outstream.flush();

}

else if (remotemethod.equals("age")){

ObjectOutputStream outstream

= new ObjectOutputStream(socket.getOutputStream());

outstream.writeInt(myperson.getAge());

outstream.flush();

}

}

}catch(Throwable t){

t.printStackTrace();

System.exit(0);

}

}// End of run()...

}

④ Stub: Person_Stub.java

import java.io.ObjectOutputStream;

import java.io.ObjectInputStream;

import java.net.Socket;

public class Person_Stub implements PersonInter{

Socket socket;

static final int PORT_NO = 9000;

public Person_Stub() throws Throwable{

// Create a network connection to the skeleton...

socket = new Socket("localhost",PORT_NO);

}

public String getName() throws Throwable{

// Send the method name 'name' to the skeleton...

ObjectOutputStream outstream

= new ObjectOutputStream(socket.getOutputStream());

outstream.writeObject("name");

outstream.flush();

// Receive the result from the skeleton...

ObjectInputStream instream

= new ObjectInputStream(socket.getInputStream());

return (String)instream.readObject();

}

public int getAge() throws Throwable{

// Send the method name 'age' to the skeleton...

ObjectOutputStream outstream

= new ObjectOutputStream(socket.getOutputStream());

outstream.writeObject("age");

outstream.flush();

// Receive the result from the skeleton...

ObjectInputStream instream

= new ObjectInputStream(socket.getInputStream());

return instream.readInt();

}

}

⑤ Client: PersonClient.java

public class PersonClient{

public static void main(String args[]){

int age;

String name;

try{

// Person_Stub implements PersonInter...

PersonInter personinter = new Person_Stub();

name = personinter.getName();

age = personinter.getAge();

System.out.println(name+" is "+age+" years old\n");

}catch(Throwable t){

t.printStackTrace();

}

}

}

- Execute the server and client...

#java PersonServer &

#java PersonClient

David is 12 years old

Person

Client

Client

JVM

Person

Server

Server

JVM

Person_Stub

Person_Skel

PersonInter

PersonInter

'User'-generated

'System'-generated

Protocol

∙Protocol

- Connecting the stub to the skeleton.

- Passing parameters and returning the result.

- Handling errors and exceptions.

- Passing transaction and security context.

- etc.

Ex) Java RMI, IIOP (CORBA), DCOM

□performance

Java RMI

∙Service

- Remote Method Invocation: Allows 'transparent' calls to methods in remote machines.

- RMI provides a 'registry' service that runs on the server.

⇒ Registry maintains a database of 'named' remote objects.

⇒ Once a reference of a remote object is obtained from the RMI registry, it is possible to call methods of that object in the same way as methods of local objects.

Client

Server#!

object

reference

Server#2

Registry

Server#1

Server#2

…

Server#2

Server#2

ID#1

ID#2

- RMI goes RPC one better by automatically 'marshaling' and 'unmarshaling' objects as well as primitive values by using Java serialization facility.

⇒ Marshaling: Converting the value from primitive types (integer, floating point, etc.) to ASCII for network transfer.

Unmarshaling: Restoring the value from ASCII to primitive types.

∙Architecture

- Java RMI is built on top of TCP connections.

Client

Object

Client

JVM

RMI

Registry

Remote

Object

Server

JVM

DB

②Request for

reference to

server

③ Method

invocation

Stub

Skeleton

Interface

Interface

④ Marshaled

parameters

⑦ Marshaled

return value

⑧ Unmarshaled

return value

⑤ Unmarshaled

parameters

⑥ Return value

①Registration

request

Server

Object

- How it works?

① A server object creates a remote object and registers it to a local registry.

② When a client wants to use a remote object, it connects to the remote registry and asks by 'name' for a 'reference' to the remote object.

⇒ The registry scans its database and returns a reference to the requested object.

③ The client invokes a method of the remote object at the local 'stub'.

④ The stub 'marshals' the parameters and sends a message to the associated skeleton on the server side.

⑤ The skeleton 'unmarshals' the parameters and invokes the appropriate method.

⑥ The remote object executes the method and passes the return value back to the skeleton.

⑦ The skeleton marshals it and sends a message to the associated stub on the client side.

⑧ Finally, the stub unmarshals the return value and passes it to the client.

∙RMI Protocol

Stub

Registry

Skeleton

'Hello World'

Server.sayHello

TCP#1

Header

Protocol Ack, EPId

EPId, lookup()

ServerRef

TCP#2

Header

Protocol Ack, EPId

EPId, dirty()

Lease

DGCAck

Ping

Ping Ack

Ping

Ping Ack

sayHello()

'Hello World'

clean()

clean result

①

②

①

③

④

①

⑤

①

⑥

⑦

① A new TCP connection (TCP#1) is established between the client (stub) and the registry. The registry returns an ack. of the RMI protocol and the client's IP addr. (EPId).

② The client requests the 'remote reference' of the desired remote class. And then, the RMI connection is closed, logically closing the TCP#1.

③ A second TCP connection (TCP#2) is established between the client (stub) and the server (skeleton).

④ The client-side Distributed Garbage Collection (DGC) requests a lease of required 'remote reference' from the server through a Dirty() invocation. And then, the RMI connection is closed, logically closing the TCP#2.

⑤ The client verifies the TCP#1 through a ping to open a new RMI connection. And then, it tells the DGC of the registry that it obtained a remote reference.

⇒ Before this DGCAck has been received from the client, the registry must not release its server reference.

⑥ In parallel with the step ⑤, a ping round-trip takes place for a new RMI connection. And then, the client invokes the remote method and obtains a return value.

⑦ When the client does not need the remote reference any more, it sends a 'clean' msg. to the server.

∙Programming

- All objects sent via RMI as arguments or return values must 'implement' the Serializable interface.

⇒ If an argument or return value cannot be serialized, the remote method call fails.

- A remote method call can throw a RemoteException, which must handled by a user program.

- rmic: Java provides a tool that automatically generates the stub and skeleton from a compiled .class file.

Ex) #rmic FrisbeeServer

⇒ generates FrisbeeServer_Stub.class and FrisbeeServer_Skel.class

Ex) ScoreList: Execute remote methods in the ScoreListServer object.

Client-side	Server-side
ScoreList.html Score.class ScoreListClient.class ScoreListInterface.class ScoreList_Stub.class	Score.class ScoreList.class ScoreListServer.class ScoreListInterface.class ScoreList_Skel.class

- Define remote objects in the server

(score.java)

import java.io.Serializable;

class Score implements Serializable{

String homeCity;	// key attr.

String homeTeam;

String visitorTeam;	// key attr.

int    homeScore;

int    visitorScore;

int    currentQuarter;

public Score(String hcity, String hteam, String vteam,

int hscore, int vscore, int cquarter){

homeCity=hcity;

homeTeam=hteam;

visitorTeam=vteam;

homeScore=hscore;

visitorScore=vscore;

currentQuarter=cquarter;

}

public String getKey(){

return homeCity+" vs "+visitorTeam;

}

public String toString(){	// make a tuple...

String s=homeTeam;

s+=" vs "+visitorTeam+" at "+homeCity+": "+homeScore+"-"+visitorScore;

s+=" ("+currentQuarter+" Q)";

return s;

}

}

(ScoreList.java)

import java.io.Serializable;

import java.util.*;

public class ScoreList implements Serializable{

Hashtable scoreList=new Hashtable();

public void putScore(Score score){

String key=score.getKey();

scoreList.remove(key);

scoreList.put(key, score);

}

public Score getScore(String key){

return (Score) scoreList.get(key);

}

public String[] getGames(){	// get all games.....

int elemcnt=scoreList.size();

String[] games=new String[elemcnt];

Enumeration elements=scoreList.elements();

for(int i=0;i<elemcnt;i++){

Score score=(Score) elements.nextElement();

games[i]=score.getKey();

}

return games;

}

}

(ScoreListServer.java)	// registers remote methods to the local registry...

import java.rmi.*;

import java.rmi.server.*;

public class ScoreListServer extends UnicastRemoteObject

implements ScoreListInterface{

static final String SERVERNAME="scorelist";

ScoreList slist = new ScoreList();

public static void main(String args[]){

//    if(System.getSecurityManager()==null)

//      System.setSecurityManager(new RMISecurityManager());

try{

ScoreListServer server=new ScoreListServer();

Naming.rebind(SERVERNAME, server);	// registers this object by 'scorelist'...

System.out.println("scorelist Server is ready...");

}

catch(Exception ex){

ex.printStackTrace();

}

}

public ScoreListServer() throws RemoteException{

slist.putScore(new Score("Denver","Broncos","Dolphins",6,0,1));

slist.putScore(new Score("Dallas","Cowboys","Packers",6,7,2));

}

public String[] fetchGames() throws RemoteException{

return slist.getGames();

}

public Score fetchScore(String game) throws RemoteException{

return slist.getScore(game);

}

}

- Define Interfaces (ScoreListInterface.java)

import java.rmi.*;

public interface ScoreListInterface extends Remote{

// List remote methods in the server object...

public String[] fetchGames() throws RemoteException;

public Score fetchScore(String game) throws RemoteException;

}

- server에서...

#javac score.java ScoreList.java ScoreListInterface.java ScoreListServer.java

#rmic ScoreListServer

// move ScoreListServer_Stub.class to the client...

#rmiregistry &

#java ScoreListServer &

scorelist server is ready...

- Define a client object in the client

(ScoreListClient.java)

import java.applet.*;

import java.awt.*;

import java.awt.event.*;

import java.rmi.*;

import java.rmi.server.*;

public class ScoreListClient extends Applet

{

// 'scorelist' is a registered server object by name in the server

static final String URL = "rmi://comedudb2.cs.ucla.edu/scorelist";

Button   theFetchGames  = new Button("Fetch Games");

Button   theFetchScore  = new Button("Fetch Score");

Choice   theGames       = new Choice();

TextArea theScore       = new TextArea(20, 64);

FetchScoreHandler theFetchScoreHandler = new FetchScoreHandler();

public void init()

{

setLayout(new BorderLayout());

Panel p = new Panel();

add(theGames, BorderLayout.NORTH);

add(theScore, BorderLayout.CENTER);

add(p, BorderLayout.SOUTH);

p.setLayout(new GridLayout(1, 0));

p.add(theFetchGames);

p.add(theFetchScore);

theScore.setEditable(false);

theScore.setFont(new Font("Monospaced", Font.BOLD, 12));

theGames.addItemListener(new GameHandler());

theFetchGames.addActionListener(new FetchGamesHandler());

theFetchScore.addActionListener(theFetchScoreHandler);

}

public void fatalError(Exception ex)

{

ex.printStackTrace();

}

class GameHandler implements ItemListener	// Event Listner...

{

public void itemStateChanged(ItemEvent evt)

{

String choice = theGames.getSelectedItem();

theFetchScoreHandler.fetchScore(choice);

}

}

class FetchGamesHandler implements ActionListener	// Event Handler...

{

public void actionPerformed(ActionEvent evt)

{

try

{

theGames.removeAll();

// Try to find a remote object...

ScoreListInterface server = (ScoreListInterface) Naming.lookup(URL);

// Execute a remote method...

String [] games = server.fetchGames();

for (int i = 0; i < games.length; i++)

{

theGames.addItem(games[i]);

}

}

catch (Exception ex) { fatalError(ex); }

}

}

class FetchScoreHandler implements ActionListener	// Event Handler...

{

public void actionPerformed(ActionEvent evt)

{

fetchScore(theGames.getSelectedItem());

}

public void fetchScore(String game)

{

try

{

// Try to find a remote object...

ScoreListInterface server = (ScoreListInterface) Naming.lookup(URL);

// Execute a remote method...

Score score = server.fetchScore(game);

theScore.setText(score.toString());

}

catch (Exception ex) { fatalError(ex); }

}

}

}

- Excute a client object in the client

//Convert a ScoreList.html file by using a HTML converter for IE...

D:> HTMLConverter

//Execute the ScoreList.html in the browser...

- CallBack mechanism: server가 client의 remote method의 result를 받음.

Client

Object

Client

JVM

RMI

Registry

Server

Object

Server

JVM

Client_Skel

Client_Stub

ClientInter

ClientInter

ServerInter

Server_Stub

ServerInter

Server_Skel

CallBack

Call

CORBA

∙History

- CORBA (Common Object Request Broker Architecture): Distributed object middleware specification

- CORBA 1.1 was established in 1991 by the OMG (Object Management Group).	⇒ Commercial products have been introduced in the market since then.

- CORBA 2.3 was announced in Dec. 1998.

⇒ CORBA 2.5 is currently available.

⇒ CORBA 3.0 is presently in progress.

- CORBAservices (http://www.omg.org)

∙Architecture

- ORB (Object Request Broker)

□Provides comm. between the server and client objects

⇒ An object on the client can execute the methods of another object on the server.

⇒ Not necessary for the client to know detail information on the server object.

⇒ Needs only to know 'interface' information with the server objects.

- Server objects are registered on the Object Adapter.

⇒ Manages communication with the ORB for many objects.

⇒ Object location management

- Method Invocation

① Static Method Invocation: Hard-code the name of the server and the name of the object that it wants to contact at 'compile' time.

② Dynamic Interface Invocation: Use DII to discover which objects have the required interface at 'run/execution' time.

- Comm. through standard protocols such as General Inter-ORB Protocol (GIOP) and Internet Inter-ORB Protocol (IIOP) that is especially designed for the ORB comm. on the TCP/IP network.

- ORB Products

□JavaIDL (Sun)	: http://java.sun.com/products/jdk/idl/

□JacORB (Gerald Brose): http://www.jacorb.org/

□Orbix (IONA)	: http://www.iona.com/

□ORBacus (IONA)	: http://www.ooc.com/ob/

□OmniORB2 (AT&T Lab. Cambridge): http://www.uk.research.att.com/omniORB/

□Visibroker (Inprise)	: http://www.inprise.com/

□e*ORB (Vertel)	: http://www.vertel.com/

∙Programming

- IDL (Interface Definition Language): Describe the "interface" that a remote object has.

∙Advanced CORBA

- POA (Portable Object Adapter)

- IIOP

- Naming Service

- Event Service

- Dynamic Invocation

Enterprise JavaBeans (EJB)

∙Services

- Specification for the Component Transaction Monitor (CTM): Hybrid of 'traditional TP monitors' and 'ORB technology'.

- Sun Microsystems' definition

The EJB architecture is a component architecture for the development and deployment of 'component-based distributed business' applications. Applications written using the EJB architecture are 'scalable, transactional and multi-user secure'. These applications may be written once, and then deployed on any server platform that supports the EJB specification.

- Provide an infrastructure that can automatically manage transactions, object distribution, concurrency, security, persistence, and resource management.

⇒ The ultimate application server

∙History

- In Dec. 1997, Sun Microsystems released the first draft specification of Enterprise JavaBeans, EJB 1.0

- EJB 2.0 that is avaiable provides

□Plaform-independent/reusable components

□Integrated XML-based data interchange

□Unified security model

□Flexible transaction control

□etc.

∙Architecture: J2EE platform

DB 1

DB n

DB Servers

Browser

…

J2EE Server

User 1

Clients

Appl. Server

User m

JDBC Obj 1

…

JDBC Obj n

Web Server

Wired/Wireless Network

Aplication

Client

Aplication

Client

Container

Enterprise

Bean m

EJB

Container

Servlet

Web

Container

JSP Page

Enterprise

Bean 1

1. J2EE server

Ex) Currently available servers

① Commercial

WebLogic Server (BEA):	www.beasys.com

WebSphere AS (IBM):	www.software.ibm.com

SilverStream AS (Silverstream):	www.silverstream.com

Oracle 9i AS (Oracle):	www.oracle.com

Dynamo AS (ATG):	www.atg.com

② Open Source

J2EE 1.3 SDK	(Sun):	java.sun.com

JOnAS (Objectweb):	www.objectweb.org

Enhydra (Lutris):	www.enhydra.com

Ex)	□start the server (after installing the J2EE server)

#j2ee -verbose &

□stop the server

#j2ee -stop

2. J2EE components: Self-contained functional S/W units

① J2EE clients

Ex) application, Applet

② Web components

Ex) Servlet, JSP

③ Business components: session/entity/message-driven beans

Ex) EJB

Type	Purpose
session	performs a task for a client ⇒ a transient 'conversation' with a client
entity	represents a business entity object that exists in persistent storage (disks) ⇒ persistent data stored in one row of a DB table
msg-driven	combines features of a session bean and a Java Message Service (JMS) msg. listener. ⇒ receive JMS msgs asynchronously.

- J2EE components are

□Assembled into a J2EE application

□Verified that they are well-formed and in compliance with the J2EE spec.

□Deployed to production where they are run

□Managed by the J2EE server

- Resource adaptor: data source connectivity

Ex) Enterprise information systems

□DBs

□Enterprise Resource Planning (ERP)

□Mainframe transaction processing

□Other legacy information systems

3. J2EE containers

- Components are assembled into a J2EE 'application' and deployed into its 'container'.

cf.) stub and skeleton.

- The interface between a component and the complex low-level comm. details.

① Configurable services: 'Customize' the services provided by the J2EE server.

□transaction management

⇒ all methods in one transaction are treated as a single unit.

□security

⇒ resources are accessed only by authorized users.

□Java Naming and Directory Interface (JNDI) lookups

⇒ components can access naming and directory services.

□remote connectivity

⇒ a client component can invoke remote methods.

② Non-configurable services

□life cycle management

⇒ enterprise bean and servlet

□DB connection resource pooling

⇒ multithreading

□data persistence

⇒ data is saved if the server shuts down

□access to the J2EE platform APIs

4. Packaging

- A J2EE application composed of modules.

- Followings are assembled into a 'module'.

① each component

② related files (GIF or HTML files)

③ server-side utility classes

④ deployment descriptor (DD)

- DD

□an XML document

□describes a component's deployment settings.

Ex) transaction attributes, security authorizations, etc.

□At run time, the J2EE server reads the DD and acts upon the component accordingly.

5. Deployment

- A application with all of its modules is delivered in an Enterprise ARchive (EAR) file.

⇒ A standard JAR file with an .ear extension

① EJB JAR: a DD, the enterprise bean files, and related files.

② Appl. client JAR: a DD, the class files, and related files.

③ WAR: a DD, the Web component files, and related resources.

- Create an EAR file first and add JAR and Web ARchive (WAR) files to it.

⇒ Use the J2EE SDK application deployment tool.

Ex) #deploytool

□packaging, configuring, and deploying J2EE applications

□packaging and configuring enterprise beans/ web components/ application clients/ resource adaptors

- Assembling various modules into a EAR files

⇒ Makes it possible to assemble a number of 'different' J2EE applications.

⇒ 'No extra' coding is needed.

∙Programming

- J2EE SDK 1.3 includes

분산 컴퓨팅 서비스

웹상에 DB들이 급증함에 따라 사용자들은 여러 DB로부터 데이터를 접근하기를 원한다. 예를 들어, 여러 회사가 가전제품을 판매하고 있는 경우, 사용자들은 여러 가전회사의 제품들을  살펴보고 비교하기를 원할 것이다. 더 전통적인 예를 들면, 대규모 조직에서는 보통 판매ㆍ제조ㆍ구매와 같은 서로 다른 부문에서 생성ㆍ유지ㆍ관리하는 여러 개의 DB들을 가지고 있다. 이 DB들이 관련 자료들을 가지고 있을 때, 서로 다른 DB에 있는 테이블들 간의 정확한 관계를 파악해야 하는 경우가 생기는 것이다.

이러한 이질적인 DB들을 연결하는 통합 DB시스템을 구축하기 위해서는 ‘DB들 간의 게이트웨이(gateway)’ 표준의 설정이 중요하다. 게이트웨이라는 개념은 요청을 받아서 이를 해당 지역의 DB에 보내고, 그 후에 그 결과를 설정된 표준 양식으로 요청자에게 반환하는 일종의 ‘관문 소프트웨어’라고 볼 수 있다. 게이트웨이를 통해 각 DB 시스템에 접근함으로써 그들 간의 차이점(데이터 포맷 등)은 가려지고, 같은 분산 시스템 내에 속한 여러 DB 서버들 간의 차이점을 상당 부분 일치 시킬 수 있게 된다.

그리고 여러 DB들이 서로 다른 DBMS로 관리되고 있다면 어떤 종류의 ‘미들웨어(middleware)'라는 것을 사용하여 서로 다른 DB들을 관련ㆍ통합 접근이 가능하게 된다. 미들웨어 방식에서는 미디에이터(mediator)라는 가상(virtual) DB를 지원하는 소프트웨어 요소를 사용하며, 사용자가 마치 DB가 물리적으로 저장되어 있는 것으로 생각하고, 요청(query)을 수행할 수 있도록 해준다. 미디에이터는 실제로는 데이터를 저장하고 있지 않으며(no large, central and  star-schema-based repository), 사용자의 요청(global query)을 각각의 해당하는 정보 소스 DB에 대한 다수의 질의(local query)들로 변환하여 전달하고, 각 소스 DB로부터의  결과를 취합하여 사용자에게 질의 결과를 전달하는 역할을 수행하는 것이다. (그림 15 참조)

그림  분산 DB를 위한 구조

미디에이터

게이트웨이 #1

게이트웨이 #n

기관

DB 1

기관

DB n

사용자 요청

통합

결과

미들웨어(middleware)

웹 서비스 (Web Service)

분산 컴퓨팅을 구현하기 위해서는 웹 서비스 기술을 이해할 필요가 있다.

(1) 기존 분산 컴퓨팅 프로토콜의 문제점

컴포넌트 기반의 분산 컴퓨팅에 사용되는 대표적인 프로토콜로서는 OMG의 CORBA 표준 프로토콜인 IIOP와 마이크로소프트사의 DCOM, 그리고 Sun사의 RMI 프로토콜이 있다. 이런 프로토콜을 사용해서 클라이언트 응용프로그램 또는 웹 컴포넌트는 다른 서버에 존재하는 원격 객체의 메소드를 호출할 수 있다. 이것을 보통 원격 프로시저 호출(RPC)라고도 부른다.

이들 프로토콜의 공통점은 연결지향(connection-oriented)이라는 것이다. 클라이언트는 우선 서버와 연결을 만들고, 연결된 상태에서 서버쪽 원격 객체의 메소드를 실행해 달라고 요청한다. 이런 연결 지향적인 프로그래밍 모델은 대략 네 가지 문제점을 가지고 있다.

첫째는 연결된 상태에서 갑작스런 끊김이 발생했을 경우 적절히 대응하지 못한다는 것이다.

둘째는 수 천 개의 클라이언트가 서버에 연결되어 있는 경우, 이미 비활동 중인 클라이언트로 인해 서버 쪽의 귀중한 자원이 낭비될 수도 있다는 것이다.

셋째는 연결 지향적인 프로토콜은 대부분 방화벽을 통과하지 못한다는 것이다. 다시 말해서 보안이 강화된 인터넷 상에서 컴포넌트 기반의 분산 컴퓨팅이 어렵다는 것이다.

넷째는 프로토콜의 구조가 모두 다르기 때문에 같이 사용하기 힘들고, 프로토콜 자체가 복잡하다는 것이다. 이들 프로토콜 간에는 호환성이 없기 때문에 같은 프로토콜을 사용하는 클라이언트와 서버 간의 통신만 가능하다. RMI, CORBA, DCOM 모두 마찬가지이다.

이런 문제들의 해결을 위해 웹 서비스 기술이 탄생되었다.

(2) 웹 서비스란?

웹 서비스 관련 기술 및 스펙을 제공하는 주요 업체에서 제시하는 웹 서비스의 정의를 통해서 웹 서비스에 대해 알아보면 다음과 같다.

① IBM: 웹 서비스는 표준화된 XML 메시징을 통해서 접근 가능한 네트워크 명령들의 집합을 기술한 인터페이스이다.

② Microsoft: 웹 서비스는 다른 응용프로그램에 데이터와 서비스를 제공하는 응용프로그램 로직의 단위이다. 응용프로그램은 각각의 웹 서비스가 어떻게 구현되었는지 신경 쓸 필요 없이 HTTP, SOAP과 같은 웹 프로토콜과 XML 데이터 포맷을 이용하여 웹 서비스에 엑세스한다.

③ Sun: 웹 서비스는 사용자의 요청에 솔루션을 제공하기 위하여 임의로 찾아서 조합될 수 있는 소프트웨어 컴포넌트이다. Java와 XML은 웹 서비스를 위한 뛰어난 기술이다.

정리하면 웹 서비스란 ‘유ㆍ무선 웹 상에서 플랫폼과 구현언어에 독립적인 컴포넌트 기반의 분산 컴퓨팅’이라고 정의할 수 있다. 웹 서비스 시스템은 인터넷에 연결되어 있는 원격 클라이언트에 의해 호출될 수 있는 원격 프로시저의 집합으로서 서버 측 응용프로그램이다. 따라서 웹 서비스 시스템은 보통 웹 컨테이너에 배치되고 실행된다. 웹 컨테이너는 Tomcat, 웹로직, J2EE 서버 등이 될 수 있다.

(3) 웹 서비스의 기반 기술인 XML

웹 서비스에서 가장 중요한 기술은 XML이다. XML을 이용하면 각종 데이터 교환이 자유롭다. XML 문서는 유니코드로 이루어져 있기 때문에 유니코드를 인식하는 모든 시스템에서 해석 가능하기 때문이다. XML이 웹 서비스에서 가장 중요한 기반 기술인 이유는 웹 서비스의 기능 호출과 결과 등이 모두 XML 문서로 전송되기 때문이다. 웹 서비스의 원격 프로시저 호출은 XML을 이용한 SOAP 메시지로 이루어져 있고, 반환되는 결과 형식도 XML을 이용한 SOAP 메시지로 이루어져 있다.

(4) SOAP (Simple Object Access Protocol)

인터넷 상에서 가장 많이 사용되는 표준 프로토콜은 HTTP이다. HTTP는 다양한 형태의 데이터를 전송하도록 제작된 전송용 프로토콜이다. 그러나 원격 응용프로그램 간의 효율적인 정보 교환용으로는 부적합하다. 그래서 정보 교환용 프로토콜로 탄생한 것이 SOAP이다.

SOAP은 XML 문서로 구성되어 있기 때문에, 정보 표현력이 아주 우수한 프로토콜이며, 가볍고, 구조가 간단한 프로토콜이다. SOAP은 단순히 정보 전달용으로 사용될 수도 있지만, 주로 원격 프로시저 호출용으로 이용된다.

(5) 웹 서비스의 특징

① 웹 서비스 시스템과 클라이언트는 지속적인 연결을 가지지 않는다.

② 웹 서비스는 상태 정보를 유지하지 않는다. 즉, 비연결지향적이다.

③ 사용하는 프로토콜은 XML 기반의 SOAP이다.

④ 기존의 다른 프로토콜로 구현된 분산 컴포넌트 환경을 통합시킬 수 있다. 즉, CORBA와 DCOM의 통합도 가능하다.

⑤ 인터넷 상에서 방화벽을 넘나드는 분산 컴퓨팅이 가능하다.

(6) 웹 서비스의 형태

① '동기적인' 웹 서비스 형태: 동기적인 웹 서비스 형태는 요청/응답형의 메시징을 말한다. 클라이언트에서 보낸 요청 SOAP 메시지는 웹 서비스 시스템에서 처리하고, 결과인 응답 SOAP 메시지를 클라이언트에 보낸다. 이 때, 요청을 받는 서버와 응답을 보내는 서버가 같은 서버가 아닐 수도 있다.

② '비동기적인' 웹 서비스 형태: 비동기적인 웹 서비스 형태는 단방향 메시징을 말한다. 비동기적인 웹 서비스는 메시지 큐가 있거나 없는 두 가지 형태가 있다.

(7) 웹 서비스를 위한 역할

한 개의 웹 서비스를 구성하는 데에는 세 가지 역할이 존재할 수 있다. 이들의 역할을 그림 16으로 도식화하면 다음과 같다.

그림  웹 서비스에서의 역할들

① 웹 서비스 제공자 (provider): 웹 서비스 제공자는 웹 서비스를 개발하는 회사 또는 개인을 말한다. 웹 서비스 제공자는 여러 가지 비즈니스 기능을 웹상에서 이용할 수 있도록 웹 서비스 시스템을 개발한다.

② 웹 서비스 중개자 (broker): 웹 서비스 중개자는 웹 서비스 제공자가 자신의 웹 서비스 시스템에 대한 상세 내역을 공개(저장)하도록 하고, 웹 서비스 소비자에게는 자신의 원하는 웹 서비스를 검색할 수 있도록 해주는 중앙 저장소를 운영하는 회사를 말한다.

③ 웹 서비스 소비자 (consumer): 웹 서비스 소비자는 웹 서비스 시스템을 이용하는 회사 또는 개인을 말한다. 웹 서비스 소비자는 웹 서비스 중앙 저장소에서 원하는 웹 서비스를 검색하여 이용 방법을 알아낸 뒤, 원하는 웹 서비스에 바인딩(bind)하여 실제 웹 서비스 기능을 이용하게 된다. 바인딩의 의미는 특정 프로토콜을 이용하여 웹 서비스 시스템에 접속하는 것을 말한다.

(7) 각 역할별 행위에 대한 규약

웹 서비스를 구성하는 세 가지 역할인 웹 서비스 제공자와 웹 서비스 중개자, 웹 서비스 소비자는 공개(publish), 검색(find), 바인드(bind)라는 세 가지 행위(operation)를 하게 된다. 이들 행위는 세 가지 역할의 환경과는 무관하게 플랫폼 독립적으로 통신하는 것을 원칙으로 하고 있기 때문에 통신 규약과 같은 약속된 방법으로 진행되어야 한다. 그래서 세 가지 역할이 플랫폼 독립적으로 통신할 수 있도록 하기 위해 역할별 행위에 대한 규약(스펙)이 있다.

① 공개 및 검색(UDDI : Universal Description, Discovery and Integration)

UDDI는 웹 서비스의 공개(publish)와 검색(find)을 위한 XML 레지스트리의 구현과 사용 방법을 표준화한 것이다. UDDI 스펙에는 웹 서비스 중개자가 운영해야 할 XML 레지스트리 기능, 웹 서비스 제공자가 어떻게 자신의 웹 서비스를 공개해야 되는지, 그리고 웹 서비스 소비자가 어떻게 검색할 수 있는지에 대해서 언급하고 있다.

② 웹 서비스 기술 언어(WSDL : Web Service description Language)

WSDL은 표준화된 방식으로 웹 서비스의 인터페이스를 기술하는 XML 기술이다. WSDL은 웹 서비스 시스템이 제공하는 원격 프로시저를 이용하기 위해 매개변수(인수), 프로시저(메소드)명, 그리고 반환형을 기술하는 방법을 표준화한 것이다. 웹 서비스 클라이언트는 WSDL 문서를 이용해서 웹 서비스 시스템에 바인딩하는 방법을 알게 된다.

③ 단순 객체 접근 프로토콜(SOAP : Simple Object Access Protocol)

SOAP은 원격 응용프로그램 간의 정보를 교환하는데 필요한 구조를 표준화한 것이다. SOAP의 구조는 XML 형태를 가지고 있고, 전송 프로토콜로서 운반되기 위한 방법에 대해서 언급하고 있다. SOAP을 이용하면 .NET 클라이언트에서 J2EE 환경의 웹 서비스 시스템을 이용해 EJB 컴포넌트의 메소드를 호출하거나 그 반대의 경우도 가능하다.