commercial information technology group inter-operable server smalltalk and client java...

Commercial Information Technology Group

TRWInter-operable Server Smalltalk and

Client Java Architectures

Kirk D. [email protected]

Greg [email protected]

Gregory P. [email protected]

Presentation to European SmalltalkUser Group Summer School

Brescia, ItalyAugust 31, 1998

TRW Commercial Information Technology Group

Structure of Presentation

• Business Needs

• Architectural Givens

• Five Client-Server CORBA Architectures

• Benefits/Shortcomings

• Why Server Smalltalk?

• Summary/Conclusions


Business Needs

• System to Provide:– Multi-Media Content Creation– Web-based Content Delivery– Enable “Just In Time” Training– Central Administration of Content– Object-Oriented Database Storage/Retrieval– Scalable to Hundreds of Thousands of Users


Architectural Givens

• Web Clients (Netscape, IE)

• Java Clients (Applications /Applets)

• Smalltalk Clients (VisualWorks Applications)

• CORBA (Multiple ORBs )

• Server Smalltalk (VisualWorks)

• Gemstone/S Application Server/DB


Architecture I

A ny A pp lica tion

Client Application

Client ServerSystem Evolution 1

AnyC O R BA

O R B

H elp R equests/R esponse. (IIO P)

D is tribu tedS m allta lk

O R B

G em stone

D om ainO bjects

G em bu ilde r

V isua lworks Sm allta lk w ithD om ain logic

R PC or TC P /IP

S im ple In tegra ted H e lp D istribu ted S erverre turn ing he lp content

Ÿ D istribu ted A rch itectureŸ H eavy C lien tŸ Server w ith Exce llent

debugging capab ilities

N am ingService


• Pros:– Uses CORBA for Remote Messaging– No Webserver Required– Heterogeneous Language Integration– It “worked” (J. Bostrom quote)

• Cons:– Uses IIOP for Data Transfer– Heavy Synchronous Client– COS Lifecycle/Timeout Issues– Non-optimal Memory Utilization– Required Application Source Modifications

Architecture I


Architecture II

A ny A pp lica tion

Client Application


AnyC O R BA

O R B

H elp R equests/R esponse. (IIO P)

D istribu tedSm allta lk

O R B

G em stone

D om ainO bjects

G em bu ilde r

V isua lworks Sm allta lk w ithD om ain logic

R PC or TC P /IP

D istribu ted H elpApplication

D istribu ted S erverre turn ing he lp content

H elp Applica tion

W W W Browser w ithHelp Applet

?

Loca lhost (IIO P )

Ÿ D istribu ted A rch itectureŸ Asynchronous H eavy C lientŸ Server w ith Exce llent debugging

capabilities

N am ingService


Architecture II

• Pros:– Uses CORBA for Remote Messaging– No Webserver Required– Asynchronous Client Communication (non-blocking)– Minimal Application Source Modifications

• Cons:– Uses IIOP for Data Transfer– Heavy Client (Content Generation Logic)– Lifecycle/Timeout Issues– Non-optimal Memory Utilization– Instability of Large Applets Running in Browser VMs


Architecture III

A ny A pp lica tion

Client Application


A nyC O R B A

O R B

H elp R equests/R esponse. (IIO P )

G em O R BO R B

G em stone

D om ainO bjects/D om ain Logic

D istribu ted H e lpA pp lica tion

D irect C O R B A S erverre tu rn ing he lp con ten t

H e lp A pp lica tion

W W W Brow ser w ithHelp Applet

?

Loca lhost (IIO P )

Ÿ D istribu ted A rch itectureŸ A syncronous H eavy C lien tŸ In tegra ted S erver

N am ingS ervice

V isua lW orksD eve lopm entE nvironm ent

G em bu ilde r


Architecture III• Pros:

– Uses CORBA for Remote Messaging– No Webserver Required– Asynchronous Client– COS Lifecycle/Timeout Issues Minimized– Memory Requirements Optimized– Retains VisualWorks Development Environment– Gemstone Runtime Environment (Scalability, Partitioning, Native Threads)

• Cons:– Uses IIOP for Data Transfer– Heavy Client (Content Generation Logic)– Loss of Robust VisualWorks Engine for Debugging– Instability of Large Applets Running in Browser VMs


Architecture IV

A ny A pp lica tion

Client Application


AnyC O R BA

O R B

H elp R equest/Location R esponse

(IIO P)

D istribu ted H elpApplication w ith

W eb B rowser C apabilities

D irect C O R BA Serverre turn ing he lp location

H elp Applica tion

Help Application?

Loca lhost (IIO P)

W eb Server

F ile Server

C ache H TM LH elp In form ation

H TM LC om ponent

H elp R equest loca tion /H e lp In form ation (h ttp )

W eb accessib le d irectories

Ÿ D istribu ted A rch itectureŸ Asyncronous Th inner C lientŸ In tegra ted M odular Server

G em O R BO R B

G em stone

D om ainO bjects/D om ain Logic

N am ingService

V isua lW orksD evelopm entEnvironm ent

G em bu ilde r


Architecture IV

• Pros:– Uses CORBA for Remote Messaging– Asynchronous Thinner Client with Stable Java VM– Memory Requirements Optimized– Help Becomes Guaranteed Client CORBA Service– Uses HTTP for Data Transfer (vs. IIOP)

• Cons:– Loss of Robust VisualWorks/DST Engine for

Debugging– Content Generation Logic Still in Client


Architecture V

Any Application

Client Application

ServerSystem Evolution 5

Help Request/Location Response

(IIOP)

Direct CORBA Server viaServlet Translationreturning help location

Help Application

Help Application?

Localhost (IIOP)

Java Capable Web Server

File Server

Cache HTMLHelp Information

HTMLComponent

Help Request /Help Information (http)

Web accessible directories

HttpServletRequest

Ÿ Distributed ArchitectureŸ Asynchronous Thin ClientŸ Integrated Modular Server

VisualWorksDevelopmentEnvironment

Gembuilder

Any JavaORB

Java ServletBased

RequestTranslator

GemORBORB

Gemstone

DomainObjects/Domain Logic

NamingService

ClientDistributed Help

Application with onlyWeb Browser Capabilities


Architecture V

• Pros:– Uses CORBA for IPC– Asynchronous Thin Client – Java Servlets Filter http Requests Into CORBA Requests,

Allowing for Thinnest Client Possible– Content Generation Logic Partitioned to Server– Memory Requirements Optimized– Uses HTTP for Data Transfer (instead of IIOP)

• Cons:– Loss of Robust VisualWorks/DST Engine for Debugging


Why Server Smalltalk?

• Productivity Benefits (Debugging, Development)• Open (dll/c, sockets, RPC, CORBA)• Robust• Mature Class Libraries• Mature ORBs and COS Services• Many Mission-Critical Deployments• Ease of Designing New Algorithms (Caching,

Searching)


Summary/Conclusions

• Clients (Java/Browsers seem to have won the client wars)

• Server Smalltalk is Viable– Maturity

– Proven

– Premier Development Environment

– Extensible

• Smalltalk ORBs (DST, GemORB) Inter-operate Well With Other (Java, C++) ORBs


Summary/Conclusions (cont.)

• Servlets Enabled:– The right protocol at the right time

• IIOP for stable connections (e.g. IPC)• HTTP for less stable connections (e.g. Internet)

– Thinner Client• HTTP libraries are part of Java runtime• Imply server side processing

• CORBA Architectures – Good for Command and Control– High-Value Messages– Are Not Good for Bulk Data Transfer– Integrate Heterogeneous Languages and Platforms

commercial information technology group inter-operable server smalltalk and client java...

Documents