CA2168762C - Flexible multi-platform partitioning for computer applications - Google Patents

Abstract

A method of partitioning an application program by defining an application program for execution on at least two interconnected computers (7), selected from at least two classes of computers (9) without considering what specific machine environment will be used at run time. Partitioning includes defining two or more objects as components of the application program (6B), where a first object is capable of execution on one class of computers and a second object is capable of execution on a second class of computers. Once the objects are defined, the method includes selecting an environment for the application program (11), and partitioning the application program by selecting each object to execute on the computer of the corresponding class. A system using the method can generate a default partitioning scheme to partition the program as a series of partitions, each assigned to available computing resources. The original partitioning can be modified automatically or by a user.

Description

~168762 F~F.X~R~F MULTI-PI,Arlro~M PAK~ ONING
FOR CO~ ;K APPLICATIONS

Field of the Invention SThe ~ ~sen~ invention relates to mPth~s and a~alus for partitirning objects of an object-o ;r-~ed plOgl~llll across mllltipl~ cc~ u~ g devices, inC~ ng real time ...n..~ and m~ylifi.-_tir n of the p~l;l;r~

Ba~kground of ~e Im~ention 10A cc~ tur l)lo alll grn~r~l1y CQI.c~ of at least three cu~ -F-.~: a user interface; an ap~ tinn pro lalll; and n,~"ol~ or storage. Early co~ used tape or card readers and p~iflt~ for pli~ y user int~-rf~c~. The plo~lalll or applica~on was loaded to lun on ~e central ~l~C~S`;~g unit and either memory or disc storage or both provided data storage. As ~e indus~y l~lul~d~ CQ~ .J~ S were able to 15 interact with ~ . n~lc to provide _noth~or i",~ltanl user i~t~-rf~^e. Small cc....~ s, known as wu-L~ l-c, l*~ available to provide a user intPrf~r~ and CC!II~ JI;I~g power in the same unit. With the advent of p.,.50..~1 co-.~l.."e-;> or PCs, il,e~ns;ve co-.~ t~ -s have reFl~r~ simple t~ ;n~lc in many c~ ub,~ inct~ tir~nc.

In early co.. l~ute- ~, a ~Oglalll could reside only in a single cu.. -l.uler. Large prùglallls could be broken into segments which could be k~le~, as needed, into active lllC.llGl,~ in the central ~)rOC~S' ng unit. As co-..l.,,~ bec~ more powt;lrul, larger ~,~og,~.,.c could be run but the capacity of a single cc---l-ut~ r ~ in~l a fi.-u~ l limit for the size of a cc~yv~r ~roglalll.
As wu L~l;9nc and PCs bcc~ more prevalent, a paradigm evolved which ' d to ...- ;-..;,~ effir;-nr,y by using available pr~cecc;~.g power in a logical n~e(. Since many users were inte~ri~ with larger co~ ..Jtl-- . ~rough a wu.L~ n or a PC, ~l~O~ r,~ realized ~at r~.. 1;n~c lcq~d to o~-,~e the 30 user in~ ^e, such as screen l~dlawillg, video refresh, ~r~phirs gen~ l;rtn~windowing control (size, positirm and U~ ), and input yroc~c~ g (ch~r~l-ter and filnrti-~n key h~n-lling, i~ s, and such), logically should be h~nrll~l by sorlw~e which was lesldenl on the local wu-~t~l;ol- Following ~is same line of re~coring, many plO~ ullS ~uil., extensive access to CQ...l~te- storage. A classic program of WO 95/04g68 ~168 76~ PCT/US94/08785 thLs type is a f-~qtq~qQ~ where a series of records are stored in a special storage area.
One c-qt~hq-~ used by many; .~ Ds is an ~ n~l~ record. Another -qtqhqse might be for payroll or for --~4~ payable. ~3~Pnerqlly~ a . ~e ~ qtqhqQ, is co~ of a ~u~hDr of ,~cords stored in the &,~L."s sto~ge area. Mllltip'- users S can use the fl'f~f'` l`f'--QD ~;~nUlt-qneo~Q-ly~ but there must be ~ u~i~cns to p~ l two users from PesQ~ing the same record at the same time for then both would be g old ;.,rO.,. q~ .n and possibly ~.qk;.~ and storing ;~lco~ ch~.~f,~
-S de~lG~d server r...~ ..c which controlled record access for reading or writing i~-f~ , record l-~i~ and, when available J"e."G,~ or storage was 10 li-nit.~" .~ ing media c~ es such as .~u~ g or u ~ ou ~ g ~lt~,~c~ ge-qhl-media such as discs or tape.

Mqnirllqti~ ,~rhi.-- ;..rO....zt;.-.n such as windows or menu stol~cti-.n, gr~rhi~
objects and such~ ne~q-lly ,~uiles ~ fi-~ g large z.. ~.. ~c of inf.^.. ~ .n, es~ ly when .--~ qting l ;I~.~al~s ~ this irr~ must be passed over a com~ron nclwul~ shared among m ny CO-~ ~ S, then the ~ wul~ can easily be filled with t~affic lllO~ g ~rh~ ug~s~ In a similar way, the low level cc...~-..z---~s l~uiled to select a sperfir storage media, move the reading heads to the correctportion of the media and puU the ;~.fn....q~;nl~ from the media ~q.l,l~ s a fair qm~lmt 20 of activity l)el~ the controUer and the l~ad;ng heads when aU the user or ~lOg reaUy needs is the result, typicaUy so ne or aU of the contents of the reql~est~record.

This ~qrr~ has evolved to be known as a client se ~,~r. The server, in 25 g~n~rql, p~ ;des control of and access to one or more shared l~soulce,s. One useful server is a ~ ~ server, ~;c~vss~ above. Another useful server is a fi~e server, where the server has access to ~io 1~ll or data or other files and can access this i--r~ ~;n-~ upon l~uesl. A print server might store and direct print jobs to a collP-ctinn of printers which are then ~-ceQQ;hl~ to a Large .-~ of users through 30 simple calls to this server.

lhe Evo~non of Cl~ent-Server t'liPr1t se~ has grown rapidly with advances in ~qtqbq~ mqnq~gf--.e-~l system (DBMS) tPrhnol-lgy and particularly rPlqti~nql .l~l;.h~ ~qnqge~..r-~ system 35 (RDBMS) tPcl nolr!gy. The ar~l~;t,c~ s of the l^-~ing muld-user RDBMSs provide a se~ n b~ the user-s~;fi-^, work of the apFli(;q~ti~n program and the shared

- 2 -~wo 95/04g68 216 ~7 6 2 PCT/US94/08785 data mqnage-..f!n~ services of the RDBMS engine. This a~c]~ -c~..e aUows a single RDBMS engine to service multiple al~p~ ;n~ as well as multiple users of the same5p~ ;n~ Structured query lqngl~ag~ (SQL) p~.ides a~l l;c~ nC with an easy way of ~ ,esl;~ RDBMS services while ~ ~lirqti~nc from the details of data S mq~qee...~ (e.g., c~"~r~"~n~ control, backup and l~o.~, data access strategies).

With the advent of RDBMS n~,twu~Ling p~ducl~, al.l~ nc could be off loaded from the host and placed on a di~ machine, using SQL as the p~olocol to 10 co---~ ;rqt~ ~n them. At first, this t~h~nlogy was used l~t~n two rmilti Pot~ing ~ t~. S, one that ran the RDBMS engine (the back end) and the other (the front end) that drove the users' dumb tr~ c. With the growing acc~f~ of the PC, it was a logic~ step to replace a multi t-qQl~i~ front end m--hinP, with a collPrtir)n of PCs, each of which ran its own copy of the front end 15 ~pl;~sl;o~ O~ . The giUWJ~g pop~llq~ity of the y,J~l h;~l user interface (GU~ hasfur~ersoli~ ;~theappl~- ;A..~e,Sc of client3e.~cr,sincei~e~ ;vcde~
ch--.~ cycles can be used to drive the many details of the GUI.

Meanwhile, on the RDBMS server side, the ~chnnl~gy has also al~ ced.0 RDBMS ~ dols now offer multi-ll..~ded servers with ~ lo~_d ~1~ ~ c~ and ql ility. Some offer stored procedures that can speed the procec~ of p SQL ~lPriPs~ Many also offer gateways to l~ Cl~ the RDBMS vendor's SQL
dialect into RDBMSs . nd file ~:.h,.llS from other vendors.

Today, ~liP-n~ _r has come to mean PCs .~ g an a~ ir~t;rn ~rU~lalll that ~ ~ ~PQQes a sh. red RDBMS server over a n~hvolL Client-server is g~qinin~ rapid p'~ among I7O1~ 1000 co--~ s where is being used today for det,..lh-.f-~ e~c:~u~ pOl~ ~lirqti~nQ~ These co--~ ;es are very in~.~st~ in P ~ the client~er p~ ~ to ent,~ ide online a~ liC~t;nnQ0 Monolithic Cl~ent Appli~ n Prograrns Most ~liPn~ ,r developers today accept a prede~ned divis~ol of co..~l.ul;--g filncfir~nQ beh~n clients and servers. R~fi~-.;-~g to Figures lA and lB, with the most 35 cc--.~ ly used ~l~er.-~ split, clients run the P~ ?ti"n progl~ll which h~n-lles the user's dispLay and any ~ tion pl:OC4SC;~ of the data that goes into or comes

- 3 -WO 95/04968 i~ 8 r~7 6 ~ PCTIUS94/08785 out of the RDBMS. The ~ ir~lSinn lJrOg~ l passes SQL to the RDBMS int~rf~e (which also runs on the client). Thé RDBMS ;~te~ then ships the SQL across the l~twu~L to the RDBMS server which prùces~s the l~uesl and returns the r~uei.~d data or a status m~s~Ee back through the RDBMS interface to the apFlic~tinn S ~l~Ogl~ll. Acco~ g to this model, the ~rFlir~ti~n ~l~OE;~ u-l is ~ ;c and resides entirely on the client. It is a client appli~ntrQn program . This model is sQ~ -es called remote data m~n~e.~ bec~l~se the d~t~h~e iS sc~ e from the app1ir~ti-n Ogl~ll. Other models for s~litting f(lnrtinn~lity bct~.~n clients and servers are ~licc..~Qed below.
There are many high level tools on the market today for bU~ g client arF1icstir~n p . These tools typically ;~ de a screen desigr~-r and a high level e, often called a 4GL (Fourth ('Jc ~r,-~l;nn ~ e), for ~efinin~ applir,~tinnr.---- ;o~ality. Most of these tools ~ Joll rapid~.vlol~g or the abi1ity to build an 15 app1ir~tinn as an int~ctive process of w~lillg a quick ~rotoly~e and sul~s~uc.~lly refining it.

~ Cmnlithi~ client arplir~tj~n l)~O~.~...c may be well suited for ~leci~ion support involving a single RDBMS. Rllnni~ the entire apr1ir~tinn on the client, howt;ver, 20 may ~.~senl a .. ~ e~ of problems for more con~r1irst~ ~rr1i~tion~. These problems inCl~l~e:
a~lPf~ lOC4S~ power on the des~l~ to drive the en~ty of a complex aprlir~tinn pio~-~u--slow pelro .~ ce due to eYc~C~ive l~twul~ traffic iffirl11ty of int~^in~ wit-h- data sOulc~s other t-h~n the plill~ RDBMS
and those ~ ,d by the RDBMS '~,lldG 'S gat~- ~s ~1 reus~bi1ity of arFlir9tinn cc~ among multiple app1ir~tiQns Coopera~ve Processing ;..,. pa~itinning is best unde ;~od in the larger cont~yt of coopera~ive processing (an umbrella term that desc~ es the division of ap~!lir~tinn fiunctinn~litv in a l~lwul~d ~.~v~ ). It would be incorrect to ~c~.. ~ that appkca~ion5 parti~ioning is synGl,~ll,ous with cooperative processing. An und~ of the .l;on bel~._en these terms can help to il11~st~te the co~ l of this invention. To WO 95/04968 2 i 6 8 7 6 2 PCT/US94/08785 make the ~iCti~lrtit)tl, it is first helpful to look at the dirr~J t styles of coop~ ;ve yl~oce~- ~g as e . ..f~ by the Gartner Group, a market ,~ ch firm based in s~llr~, CQnrlpctirut Cd~l,~r's rlqccifirqti~n of c~yc.~i~_ y~`OC4~ styles is based on an qtinn model that ;~r~ s ~ree dilr~ u~;~ fi~lnrtionc--user p,~se.~l;Qn services, apl~1irvqtirm logic, and data mqnagPment LisPd below are four of the ways fordi~idingthesefi~.~1; .-Cb_t._e. c4 ~ Each,~ t~a Sha~ for 1aclcling dirf~ nl al.pl:r~ yrol,l~- c~ and each is supported by a dirf~.~nt set of tools. Tog.~ r they ~ ~qtP some of ~ _s ~at conLont IS ~age~s as they move from s~and alone host-based e.,~ - . -- " to client ~.~r c~n~ F-'~

Remote Data Management. This di~ on of fimr.tir~nc places the p,~..l~l;~m services and ~rplirqti~)n logic on the client, while the ser~rer pr r~.. C the data 15 mqn~g~...r..l filnrtirln~c The cb"--.--~ r~ )n y,~Otlxol l~h._en these CO--~ is SQL. See Figure 2.

Remote data mq~lage~ n~ is a very co------~ model for l..D;~.cl. ~ll ~q~-q~-qQe çliPn~ r ~plirqt;r~nc where a set of users interact with a de~y ap~lirqt~on that20 accesses a shared ,,1~;O~D1 database ~RDBMS) sever. This model can oy~lale with a character o ;F -~r~ user interface or a z~ l user interface (GU~. Many tools areavailable today for b~ ing ~lirqtirnc that utilize this model (e.g., SQL*Forms, Po~ l,uilder, Uniface, and other 4GLs).

Distrlbuted rræse,.ln~iQn This model, often called Lul~ " or "screen S~pi~," ~ ~tS adivision of rV~ ;o~ y wi~in the ~ n portion of an ap~lir~l;or~ Dic~ .d p,~sr-.'~ takes a traditional .~ -r.~---P- al~l;c~ driving 3270 sc,~e.u and aUows developers to add GUI-based ~ 5e-~t~ n services that run on a PC des~ lop. See Figure 3. The 3270 data s~eam serves as ~e co--.--.----;~ Al;.~nc pl~olocol t~l~ ^hinPs.
.

Dichi~ led p,.,S~ t~ allûws c~ ;n..C to u~ e the user intP-~ce to an e~;!c~ ap~ q5irn without qltPri~ the appli~a~ -- Several products in the market today i".ppû,l this approacl~, and they are dirr~nl products from those that 35 ~ u~l remote data ~nqnq~ nl wo 9S/04g68 2 1~ 8 7 ~ 2 PCT/USg4/08785 D~stributed Data Management. This model ~ a division of f~metion within the data mqns~,e...~ portion of an spplirsti~n With this model, dat~. canreside on more than one co~ , and a ~;`h ~ d data m~nag~ f!n~ product will coo~lin~le access to the dat.. wl,.,.~ ,. it may reside while p.~,se~ g !.~
S apFlirstirm access. ~ef~.r i~ to Figure 4, the ,1;~ g~-q~, knows which tables are on each server and routes ~ accordingly.

Di.ch jl,.~t d da~. mq~agr...f~ can be used in co~ ~o~ with remote data ' where an ~p~ ~h~ E; on the client may access data that is 10 .1; ~ d across more than one RDBMS server. A few of the RDBMS vendors offerd~ datamqna~ r~p~c1~.A~ t~ a~esQ;~d;sl~ilJ.J~d data can be developed with 1- -'1;~ 1 4GL tools.

Distributed Function. This model ~q~pli~qtir)n logic that resides on more than one machine. The cr~ ;r~Pr~ may be a remote ~rocedu~G
call ~RPC) or a more ~ .I;rmql co~ .. r.lu.~;~.. (e.g., IBM's APPC
or CPI-C). See Figure 5.

In their report Client/Server and Cool,c~ e Processing: a Guide for the 20 Perplexed, 1991, Gartner Group ol~ s: "The fl;~hil.lJt~l r...~ style is par~cularly p~ rul for complex ~ ir~;r~l~Q that are both highly user-irt~r?ctiveand d~ /o in ,....Rec~ e the fi~ c reside on the more relevant ~ocal) node, the ~....~.her of n-Pc~ges that must be sent over the ~ u~ cl~.~n Atthe client] and B [the server] is ,--;~ 1, a,c.~y engl li~ relatively ~st lesponce 25 times for complex worlr1~ 1s." Gartner also obs~l.,_s: ~i~hi~ fi1n~ti~n ~l,p1jr l;(-.~c are inl~ tly the most dimr~1t coope~ oc~-c~ g ap~lirstir~nc to design and develop, since there are two S~ t 1y CQmpi1P~ aI~pli~gti~n p~ùgl~
Devel~FP-r~ must analyze thoroughly where each r.- .e ;~ ~ should reside and what type of dialog must occur l~t~.~n the two pro~ c.n Ar)pli(~ntic~n par~foning, which is central to the ~ ~ of this i.l~e.llion, is ah~c~ logy that ~;..,ll;r.fs the devel~ -' of al.~ C using the disl,ilu~d fi1nctirm model des~ above. The gPnP~1 cl.;c.~ ,r ~igrn, 1iccuæ~ed -above, is based on a division of co~ .u~ g fi~ ;o~c among two or more nodes in a35 l~elwul]~. By dividing up co..~ g ta~ks, client-server ;.U~pOlts a flPYih1P and cost errtclive cU~ g model that may di~p1ace t~1itinn~1 host-based Co~ )u~ g as the WO 95/04968 21 6 ~ 7 6 2 PCT/US94/08785 dQ-..;n~ p~r~digm for the future. ~ r~ti~n partitinning goes beyond tr~rlition~lcliPn~ er tPrhnnl~ gy and p~u~ides an ~pproach for ~lloc~ting ~lir~tinn fi..~ ;n.ulity among clients and servers.

S The ~ll~ti~n of co~ u~;~u run~;n~C may p~senl many options, each within~pljr~tiQnc for ~. rO. ~ r4~ control, and/or flPYihility. To handle ~ ;o-.
pa.l;~;n-~ g effectively, one should concirle~ several issues j"~"o~J~ the ~lloc~tion Of filn~fi~nc across multiple ~ rO....c in ~e ~tw~llL The overall goal is to ~ o,-lo~c more erf~ client-server ~ I;o ~c that can solve e.l~ing b-~ ess pro~lPm~.
Summury of the Invention The invention p~ides a system and a ~e~l~od of par~oning an apFlir~tinn g-~ll. A develo~ ,n~ ~og-~------Pr defines a logical applic~tion dÇr~ ;n ~ for an apFlirstion p.Og-~ll by defining two or more objects as co...l o.~n~ of the 15 qpplirstinn l~logl~ll. This ~PlPctinn is made willlou~ co-.c:~ g what s~)erifir machine c~ f!nt will be used at run time.

Once the objects are ~er-.r~ in ~,Jrrrir--- detail to allow the aprlirstir~n to 0~!~ , the ~rFlirqtinn a~ or will ide.~ a specifir- en~,ilo~ for the 20 g~ljr~tj~n ~,lug~ clvdi~ at least two int~,.co .-~ co~ s. Each object is sQQigrPd to a partition and each pa,Li~on is 5~Q~ d to a target co~ vt~r and loaded to allow the applirstinn pio lalll to run. The system can g~nf " ~ a default ;l;~ g s~l~-----~ to assist the applir~-l;on ~t1mini~tr~tor with initial partitioninE.
This results in the 5~r~!lir~tirJn ~lOg~ull being ~ n~ as a series of partitions, 25 each of which is s~dgJ~d to a c~ among available Co~ g l~,sour~s. The ~rig~ y~ ;nn;~ selected by the co~ can be ,..(y~ ~ su~ ;rslly or by a user. ]~o~lifirstion can inrl~e moving an object from one par~tion to snothPr orreplirsti-u entire p~ ons. The ul~,.ll;on also i~rl~ s ~ ""~l;c ~t -~-~; -. of ~.r... "~a~r~ bottlPnp~ in oye-~ the apL~ ;nn ylo 1~" and, where 30 dpp~o~le"J~yl;~ g one ormore objects to run on ~ itinn~l CO~ in order to &nhAnc~ throllghrut or increase r~pl~ ty in the system.

The ~E!lir~tinn ylO~ l can be run easily in a new e.lvil~o~ n~ by g~ ni~lg the sr~ific partitions to run on available e l.~;r~.c--~ A single aprlir~tirn pr~g.~
35 might run within the same cu~ in a variety of dil`f~ partitinning sç~ ..P,~, based on specific ~sources and needs in a specifir- COl~Olal~; lnc~tinn.

WO 95/04968 ~ i 8~ 6 ~ PCTtUS94tO8785 As cliP-nt s~,~er evolves from a de~h~ 1 to an en~ ;se-wide ~hat~ /, qrp1irqtjnn ~I;I;n~l;~ will be a key ~llaltgy.
. Applir~qtinn partitirning is the ability to create a unified aprlie-qtinn and ~,bs~lJe-~ y break it into a set of ~od~ s that cY~tP- on dirr~ nodes in a S ~lw~ n~r~,u~
~rFlir~tinn pa~itir)ni~ can be an ~ l llat~E;y for increasing . r.. ~ , control, and flP-Yi1~ility.
P~I;I;~ g leverages the client-server model to s.~pGll a new ee ~e~ n of enterprise a~ ;n~c.
Forté was ~PCi~P~I as a tool for de~e~ E and deploying parhti~ n a~Flirqti~nc.

Brief Description of the D~
ri~ s lA and lB illllct~q-te a prior art ~O~ ;r client apI!lir~tinn p,Og Figure 2 ill~h~t~ s a prior art remote dat~a Inqnq~e,~ model.

Figure 3 i~ t~s a ~ hi~ t.~ y~ l;O-- model.

Figure 4 ill~ tJ~S a f~ Jt~r~ data ~qnag~.. e.~t model.

Figure S i~ 3h~t~s a .licl.il..,~ r,..-~ model.

Figures 6A and 6B i~ strtq-tp ap~lirqtinn p,~l;l;,...;.~p.
Figure 7 i~ ch~t~s 3-u~tl.rr aspect of sl,ylir~tinn partitinnir~.

Figure 8 ill..~ t. S proc~sCi-~p laSICS in p,qrqllP-l-Figure 9 jll~ t S impl~ -n';~ a single logical aprlirqtinn d~Pfinitirln in ~nnl~ipl~ cnnfiFIlr~q~ ns.

Figure 10 il1~sl~t~.s ~ ..e-.~ g a single logical ap~lirqti~n definitinn in a mixed cQnfi~lr~qtinn Figure 11 illuSllateS a l~lese ~ e impl~- ~.e I~l;on of ~e me~od for a ~;u~!l.. er ser~ice app1ir~ti~n.

Pigure 12 i~ tr~t~s a l~ ,S~- ~t;~e impl~ n of ~e meth~ for a S simple .~ r ~t~ring l,~ocess apFlir~ti~n Figure 13 i~ sh~t~vs a ~ .e implc~-cn~-l;nn of ~e metll~ for ~nl~th.or r~ ng ap~ ti~n.

Figure 14 ill--~h~ s a l~ impl~ t~l;n~- of ~e ~ -~ for a r ~l se,~ s ~ r~

Figure 15 ill--cl-~tP,s a ~p~ont~ implr~.f .~ ... of ~e ~ l.od for a ~;v,~ : ~ product order/en~r al~l;r~;nn.
Figure 16 ill~ t~s a ~lOE;la.l~ de~ cycle using ~e new .. etl.nd.

Figures 17A and 17B illnstr~t~, a sample ~rI~li~tinrl program as a tr~-litinn~l ~ioc~lu,~ and as a coll~-ctinn of ~./ices.
Figure 18 ill.~yt~t~ S the new de~el~p~ e.~iro~ a~ t~,c~ e.

Figure 19 ill..~l.,.1~s ~lictrilnltinn of service objects through par~itinning~

Figure 20 ill~lctr~t~s default p~i~n~ g.

Figure 21 ill ~ tfs ~ J~d e ~ ;n~

Figure 22 ill~-ch~t~s using an e.,~o~ r for .. ~ g the .i; ch il ~t. ~1 ap~lir~ti~ n Figure 23 ill~ s a l~ nin~ int~^e.

wo 95/04968 21 6 8 7 6 2 PCT/US9410878~

Description of the ~f~ l Embodiments Some gton~ efinitionc and a ~esr- ;p~;on of the overall system will assist in e~ g the ~senl invention.
s Di~tribu~ed Applic~7ti~ns A l;ct.i~ ~ apI~1ir~tinn pr~rides access to l;ch;1.u~ mzchines and se~vices through a single, integrated system. The ~ ;o.~l client-server ~ ir~tir)n runs on only two --~ -s, a ~e~ ? CO~ t~ r and a database server. Ho~ ., an 0 ~,~lir~ti~m ~iOgl.~.~ll using the new ~ r~ can run on any .------l~e~ of dir~n~
machines, which may be only two machines or may be many m~rh;neS.

A single a~ r~;nn P~OE,1~l1 can acceæ any .--~ 1 er of d;~hilJ.~ services, ; . ,r1. ~ g any .~ her of ~lzt-hz~,s (on any ~ r of ~;s~;--rt m~rhirlPs) 3GL se.~rices, such as an API to the New York stock eYch~e, a cu~ e~c;al s~tictir~l analysis ~r~g~o, or a 3GL ~M!lir~ti~n developed in-house New services, such as an image server or coo,.1;~ n facility A new aprlir-ti~n ~roE;l~ll can also lJio~ride fault tolerance and p~r~
yl~,ce-s~ by ~ ""~I;r~lly~-CeQQ;ng backupandload Ch~ gmA^hin~5.

Par~ions In order to 1;CI~;hU~P an apr1irstir~n~ Forte (the new m~th~) divides it into two or more logical ~ , called ~ ;ons. Eachpartition is an inde~ d~nl co-.~l O..f ~-~ which can run on its own .--A-hi-~e. For e ~ 1e, a ~pical end user aM1ir-ti~n has a client partition, f~enr-r~lly placed on the de~l ~op, that provides a g ;tl hiC_1 user in~~ Ae. Other ~lil;ol~s could ;--A1~-de: a DBMS server that runs on a ~ r~--e; an inuge server that runs on a ~peris1i7~d msCAhine; a 3GL service; or 30 other special services. In a ~re.l~d impl~-m~ , the ~-~c~1-r~ of the invention ;-Jk~ ;cs11y coordi-la~s all co~ n l~h.~en the p~tions.

A partition is made up of one or more service objects. To create a disll;bu~d app1irstinn requires defining any needed service object as part of the project.

-- WO 95/04968 2!1 6 ~ 7 6 2 PCT/US94/08785 Service Objects A Forte ~r~lir~tion l)~Oglalll iS made up of objects. Each disl~ ed service with which the app1ir~til~n ~.Og~ t,,~ iS an object. For e~ )1r~ a ~t~h~e ^^c~s~l from the a~ r~l;r)n l,rogl~ull is an object. Lik~ise, an eYictin~ 3GL
S apF1ir~ti~n is an object. To int~P~r~t with an object, the user or ~noth~r object invokes a mPth xi on it, which f Sse~ lly is just like i~tP~^ting with any other object in the s~lir~tir n yl~O~l~UIl.

In a ~ ;b~J~ 9p~ , every object has a single, fixed location. When a 10 m~thod iS invoked on an object, it is ~ tr~ on the ~ on which the object is

4~tP~ Normally, ~e object is loc~tP~ on the machine on which it was created.
Each senrice object can be ~ 4~,.,t. ~1 on other ~alLLons by an object l~.,ei.
broker, ~Y--~ed below.

lS ~lth~ h the a~ lirqtir~n may consist of thOlu~-nrlC of objects, only a few of these need to be at a particular lor~l;oQ, These ;~ e:
an object that represents an e ~ g e t - --Al l~sGulce~ such as a lq-tq-h-q-~e n~qnqe,~ system or a 3GL service, that is already p.43e,.l on a particular mqrlnnP, an object that p~i~es a Forte service that is going to be shared by m111tip1P.users, such as an image server {or an auction ~q~q~er for an ~q~lctinning filnrtir~n}
an object that ~ a service that will be reF1ir~q~tPA to provide filover or load bq1qnçillg When an qpp1ir?tinn is divided into ~LLolls, these central services are objects that may need to be placed on s~eÇ;rc ,-.a~ 5 The qrp1ir~tinn plo~ has the option of S~C;~illg that a sPlecte~ object 30 must be 1~C~PA on a speçifie ~tilioll by ~ aLg and nqming a serl~ice object. The qrp1irqtinn p~O~, .. ~ does not need to worry about the lo~1;~ ~c of other objects in the apI~1irqtinn p~Ogl,UIl. If a service object creates other objects, these will be loGq~ on the same partition as their creator. For coll~eQ;~Ic~ the rest of this I;nn will ~c.,~....r. that a "service object~ inr11~les related objects created by the 35 actual service object.

WO 95/04g68 PCT/US94/08785 A service object is simply a named object that can be ~ nced from any mPth~ in ~e aprliAsti~n ~Og~ . It is like a global varLable, except that ~e value can be s~;f'~ at cQn~pil~ ~me. When ~lw.ling a service object, it is ~ci~n~ a name, a class, and values for its ~ 'Vt~-S.
s On. e created, a service object can be used like any o~er object. If a user or hf r object invokes a mPth~ on a service object that is locstP~ on a remote m^AhinP, a ~ e,.l for the service object is passed through a local object request broker. A broker l~plod~ces the interface of a co~EspQ~ service object so that 10 when a .--~ od is invoked on the service object, all r~eS~C are c~ ,d by ~e local object ~uei.l broker ~en f~ ed to the actual serviee object for pioc4sc~ . Any return value and output p~ are ~ uugh the object l~ broker to the originql invoking object. Thus invoking a .--~ od on a service object that is lor-qt~ on a remote ..,~ is completely !.. ~.S~.
One special service object is a DBMS l~,s~lur~ mqna~P,r, which provides access to an ~ e ~ hqce mqn:lgP,mPnt system. The new l~ souice mqnqgPr p,v~idf,S a shell to "wrap" the ~ E; system and intercept and l~ Cl~t~-, as -Pc~s~ , all m~s~ges~ l~ue~ or data sent to or from the c-;cl;-~g system. By 20 defirlins~, a DBMS l~s~ul~ .-.q~ger service object, an e ;c~ g d~h~, mqnq~,e...~
system can be treated like any other object. The user can thus invoke .~-ell~ocls on the new l~,s.~ur~ mqnagP,r to st~t a ~-h-q-~e seS~ n~ l~hic~, dat.., update data, and so on.

E,.v~
To implement a ~ apFlir-q-~inn in a ~pecifir- e,~ o~ cn~ lf~ui~S
providing some inrQ-..-~t;nn about that e"~ An e,-~i-o---..~ is a named des~ of the l~d..~ and sorlw~ at a par~cular site, such as a par~cular co-.~ of_c~ or a par~cular dcp~h,lcnl. The same logical a~ ... decç.;~
30 can be used, wi~out n.~ifir~ti~n, to implement a rl;~hi~-lt ~ n in any ..~r Of e,"~ f'~ In ~'Aiti-~n, a single ~ can ~I ner~lly ~.
more than one ~ a~lir~tit~n To; -l,le---f,~-l a l;cl~;bu~ed applir~lt1(m l~llil~,S par~ nin~ the applir~tion for 35 the specific en~,~o~.-.. --.~ This means ~sig~ing each of ~e applir~ti- n's service ~ WO 95/04968 216 8 7 6 2 PCT/US94/08785 objects to a sreçific ~&,Lilion and ~c;rying which partition will mn on which node or m~rh;~P.

Par~ioning In a p~r~ d imp~ t-~ ;rm, the ~ ~l m-oth~ ~ ;r~1ly partitions each object of an ~rpli~ ~ti~ n p~o~ into a partition. Tbis inCl~Jd~ps ide.~lilyillg and placing each service object in a ~)altil.;U~ ,f~ ,d for ~at service object. This also ;-~el~dcs id~nliry~,g each object created by the service object and l ~i~ that object in the same ~liLon as the servi-ce object. An object ~ est broker for ~at service0 object can be created for any other ~I;on and in g~,ne~l should be created for any il;on wbich co~ an object which can invoke the service object.

Ref~P-rri~ to Figures 6A and 6B, parli*nning ~ des ~c~igning each partition to a particular node or machine in the e n~r~o~ f ~ with appro~ suu~ces and 15 cqp~bilitiPs The par~itioning can be ~ n~d and .~ ;r.r~, for example by r~ ig~in~ a certain partition to ~no!1-er node or by moving a service object to ~n--thPr ~kuliliOll.

Viewed ~-~o~ way, apFlir~ti~n par~iti~ni~ is the ability to split an 20 ~ a~ n l~loE5~ to run on t~,vo or more cc---l~u~-~,.. Whereas the mnnnlithir, client al.p~ l- model splits the ~I~Flir~ n from the RDBMS server, ~p~l;f~ n partiti~-ni~ provides a way to ~l;c~ L~te the ~p~ l;nr ~O~ itself across mllltipl.-c~ .,tu-~. Part of the apFlir~tirJn may run on the client, ~nother part m~y run on the ba~.l~ that also drives the RDBMS server, and part may run on one or more other 25 servers.

A ~ f~lcd pallilion m~y be yl~er~p~d~ for ~ lr when a serv.ice object wiU wrap an eyicti~ applir~tinn which is already l~d~ on a sperifir m~rhine. Notall pi~re~cd partitions need to be predefinP~ since m~ny service objects can mn 30 equaUy weU on a variety of m--^hinPs The ~ ti~n of srecifir partitions can bemude based on the har.l~ and soh l~ui~ of a particular service object and any co.,.,~ ;~ created objects b~l~nr~ against other service objects and available ~ '''h;~ SOul"~S.

35Once a partition has been ~c~igrP~I to a node and fully spec;rP~l, inc~ inf~ all service objects, objects, and object request brokers for that partition, the partition can W O 95/04968 21 6 8 7 6 2 PCT~US94/08785 be comrilP~ for a particular mqehinP. This may involve simply ~,~.n~.".l;n~ an ap~ ~ ;n~ .~..PAiA~ source code, such as C+ +, for cQmrilqti~n into mqr~linlo n~lq~P on the ~ er.ifir. node. The comrilp~l m-q-chinP code can be loaded on each node and the ap~lirqtion piOgla", is ready to run.
s A partition can be .--r~;r.~ at any time by a ~--~---1~- of means. A particular service object might be moved from one pal~tion to ~no~ r. In the simplest system wi~ only two nodes, the initial ~~ ;~ implements at least one senrice object on each node. The pl~ hrd allows ~J~ the service object in th~e second 10 pa~ ioll then ~ ~ the o~jnql service object, erf~cli~e~ .a~ g the loc-q-tir~nof the actual service object. This should make no dirf,.~n~ to any other object in either partition except that calls from the second ~-~AI~ e which previously were brokered are now hqndl~p~ d~cll~r and calls from the first ,..=^h:~ which previously were hqn~lP~ d~ tl~ are now brokered. If there are more than two nodes, the same15 gpne~ql principles allow l~u~ing a service object to a diCf~,.enl partition.

Aprlirqtinn pa~ g does not dictate a yl~ r. ~ split of fi~nCtirnqlity for a client ~,~ v~o~.-..f,n~ It allows the ~;uus portions of the applicqtinn to be q11~qtPd in several pos~ ways. It ~cog~ s that the ap~,o~ e division of 20 ~I~r1ir~tjnn fi~nctinnq1i~y among clients and servers is highly a~ epen~1pnt-And even for a given ~p~lirqtinn, the optimal division may change over time with the ~litirm of new users and s~licqtinn ~ c:.,,,c With par~itiQni~ an ~rrlir9tinn pLO~ I can be bu~l~ as a cQ1lP~ctirm Of 25 service objects and depl ryed as a ~ d a~ , parhtinnillg allows a deve1~...f-~ Og~ r to place ~I~r1ir~tion fi1nrtinn~1ity on servers as well as clients. It ~ t -s the ~",---~ ;r~;on~ among the dirr~ 9ppli~tit~n pa~o~7s SO
that the ~I~r1ir~tinn will fi1nctinn the same ~l~ it runs entirely on the client or is t~d across several m~ ;rtPs.
A~pl;~ ;n~- p~l;l;n..;~ iS based on the CQ"~4pl of dGc4-,p1;--g the develol.",el, of an ~ ic~tinn~s funrtinn~lity from the dcc~ of where the ~aliuus ap~lic~ti~n Co~ s WiU run in the deplo~",fnl cQnfie~- .I;n~ A developer l~ro~ r can build a logical applic~rtion de~on that is ;-.~le~ F.~I of the underlying physical 35 (,.~ fnl After develûp",~nt, the logical ~rp1irs~inn de-finition is par~ (i.e., split apart into in~lf,~.~Fnt m~ lPs that can eYecl~tP on dir~ nodes in a nclwul~) --wo 95,04g68 ~ ~ 6 8 7 6 2 PCT/US94/08785 and co~ ;cqtinns are s~tn~ y set up, freeing the develo~ l progrrqm~nP.r from ~q1ing with co~ rqtionC during the apFlirqtinn A~finitic~n cycle. RPfPrri~gto Figure 7, a logical applirqtinn definiti~n i_ built as a collP-Pion of service objec$s that runs in a single address space even though it is ~lb~q~r ~ly d;C~ "ut~li over two S or more ~OC~5C~JS. After partitinni~ the spp~ n still ~senls a unified system view, allowing an applir~tinn a ~ iCl~tor to mqvn-q-~e all the co~ c~l partitions from a single user int~.f~c~.

PartitinnP~ qrFlirqtionc provide the basis for an a~ on a,~l it~c~ that0 ç~n~s the realm of qpFlirqti~n filnrti~n~lity and introduces several op~i~r C for -r..-~.R ~e, rÇliq~ lity and control. ~prli~ti~n parti~ mi~ can help o~ ;nnc errec~ ly use the clien~ r model to build new enterprise-wide online apFlirqtion~ that contqin more fi~nCtinnqlity~ Yc.co...~..n~zt~, more users, and are subject to rapidly evolving bl~ SS5 Principles of App1ienh.'on Part7honfng To be errt;-,live, ~ g should follow the following principles:

1. A parti~ioning scheme can be altered withou~ modifying the logical arplienhon definfnon. The dCr~ ;n~ of the a~ lir~ n ~ C~;n~Ulity should be i...lf,~.n.lf...~ of the pa~ ;n.~illg s~ r-~r . The ~rplirqtiQn ~f r. .;~;~ -- should be c.,v~u..-...~ nPll~l. It should be pos~ e to split the a~ ;nn in a .---~ r of dirr.,~ pLaces willlolll qltP.ring its fimr,tiQnqlity. It shouId be possible to increase the 25 n~ bf~( of pa,lilions for a given ~ lirqtion if, for r ;~ lc, a new server is added to an P~i~in~ cllvi~ f-~

2. The parhtioni~g model must be able to ac~"." odate an u~bilr~.~ numberof partitions rur~ung on m~ple n~n~ hi~.~s The ~I;~;nl-;-,~ sr,l~..e should not 30 s~c ~ ..e that all ~ ;onC will be split to mn on ~e same .~ " of nodes (e.g., a client and a d-q-tqt~qQP, server.) It should not q-cslrnP- that all clients are idçnticql. It should not qQnlmP, there is only one server (or any other .~ ker ). It should not seek to split out a certain type of fi--~ Ality (e.g., ~ rss rules) as the basis for ~ S.-;~. It should not ple,,.u"e the ple~.lce of a ~ q~ system. Tn~t~Pq~l~ it 35 should ~ p~ a very flPYihlP- partitir~ning model ~-vith no limitq~lnQ on the number of posQ;hlP partitions.

WO 95/04968 21 6 ~ 7 62 PCT/US94/08785 3. A single appl~cation definition can support m~iple G~VirV,u,~ , each with its own parti~ioning scherne. Since the ~ i~tion dçfini*on iS nd~ P,nt of a par~cular partiti~nin~ scl~ -, it should be po~QQ~ P to ~ dilf~nl e.~ Q~.-..r.--lc with the same ~ ;n.~ der;-.~ It should be possiblç, for example, to deploy the S same a~ ;nn at two sites, each with its own l~.l~ , cQnfi~tinn and 4. Individual partitions should be able to ~ate and respond to cormn~ trons with otherpar~tions. Since a p~li1;n.~ scl~ e can i~r~ e 10 multiple servers, a . erver should be able to interact dil~:tly with other e~
Servers should also be able to send a mPs~ to ~c ~ ~ clients which can then ~ucess those ...~ ae~ s.

Pa~titioning Appli~tron~
There are several ~asons to partition app~ tinn filn~ti~m~lity across mllltir~^
m~^hinPs Perforrnance. Simple RDBMS apFli~tir~n~ (e.g., l~~ g a screen of data into a ~1 l h~, or 5~lr~1;~ a record from a ~ h~.) are not the ~,.-,~ c~n~ t~s 20 for ~ g ~,. r~ nf~ wjth pa~ . H~ r~ qti~nc that ~,r~
analysis, access multiple data so~ces, and/or or~ st ~- a multi-step l,~ n~ss ~ocess may get ~-~bs~ rO-~ r~ gains with partitionin~. These gains can berealized with one or more of the following s~,-t~ ~jes.

Red~ce Network Traf~ic. For starters, p~~ n;~E can move dat analysis/reducfi~ n closer to the source of the data. This could be helpful, forexample, if a user wanted to idenlif~ the stock that c~ ged the most in value since the previous day. If the analysis to ide~ that stock Nns on the client, then the~Iqtq~--e would need to send l1.o..c~ s of ~ ds across the nctwo,l~ to the analysis 30 m~llllP. On the other h. nd, if the analysis is ~. rO ---~d on the server, only one record needs to be sent across the n~ twu,L.

Par~iti~ni~ can also be used to eY~P~ltP several se~ e l,~c;~sc steps with a single l~lwolL round trip. For eY~nple, an order entry ap~ may first verify a 35 c~ -'s crPAit, then co~r~u~ a dicco~ then check the s~lir~in~ schP~ lP, and finally enter ~e order. With par~itinnin~ all these filnctionc could be pL~ced on a ~ wO 95/04968 ;~16 ~ ~ 6 2 PCT/US94/08785 server so that the entire order/entry pr~ss could be ~eco~ ;cl.~d wi~ a single c~." .~ r~l;rJn round trip. This ~ ~o-~ r4 Sha~g~ may be very i.~ if the l~lw~L link to the client is slow, such as when portable co~ t~ ~ access a server via a mrAem, In genP~l, the more steps an ~!lir"tirn must ~ F-~uo" the greater the

5 po~ for op!;~ .;~ ~.r.,.~ nr~ by placing fi..~ lity on one or more se.~el~.

Process AI)pli~ n Tasks in Parallel . The previous order/entry eY~n~p s how partitinni~ can .."~ o~,e ~f- r~ 4 for a sequential multi-step ~rrlir~tirm. A d~r~ l Shat~r may be apr~ lP when an ~ l;r~ can eYP-a~tP
10 ;~-~e~-n~ tasks in p~ P,l~ such as analyzing the project~d return on a pl~osed stock ~ur~La~ against h~ 1 data and analyzing how the addition of that stock would impact the in.e~lu,'s indiv;d~l p~ lio Sh~Lte~y. From a b~C ~.PCC st~ld~oinl, both analyses are needed to satisfy the ~ r, but they can run in p~11P1 since itdoes not matter which completes first. From a ~r~ Al s~ ~d~ i~-l, if both analyses 15 were run on the client, they would need to run seqv~ y (unless the user had awu~ l;r,-- with ~"..-... ~;~1 m~ s~ g). p~ g offers the option to move one of the analysis ~dv1es to a server so that it could e~ ,~,ut~ CQ~ -e l~ with the second analysis n-~111P running on the de~l~p. ~ll - . zl;~ly, with ~ , each analysis m-y31l1P could be loc~tP~ on its own server. See Figure 8. This could be a 20 c~ r~ l ~.. r~.. ,.,~.-r4 win if the analytical mo~ ps were cQn~p1PY and/or the pl`~CeQ~ '~g power of the server is ~L~b~ ;Ally gr_ater than the ~e ~ hinP.. By running multiple taslcs in p~11P1, an entire ~!lir~tir~n can complete with a shorter e~ time.

(~aoad Prooessing from an Ol~erloaded Client. Some ~1ir~tinnQ grow to the point where they simply overload the target client m~^hine~ even after tr~itinn~l ,. r~.. -.. ce ~ P.I;~.s such as l~,co~ e as much of the ~ tinn as possible in a 3GL, using stored l.,oc~lul-_s to do as much work as posQil lP- within the RDBMS, and up~ the l~d~ c~nfi~ l;o~ of the client. P~u~;l;O ~ can help by 30 ~ in~, portions of the apF1ir~tinn off the client and onto a server. Even if this Shab.,g~ results in -~-litinn~l llCtw~lL c~""."".~;r~l;n~ I;chi~ g the a~ r~l;nnoften offers a net ~,. rO....~--r~ gain.

Con~rol. Whereas des~top m~rhines offer cost effective ylOC~-5S;~ power, 35 they are the most ~liffiru1t e.,vi[o~ to control. By 1OMting critical portions of app1ir~tinn fimrtinn~1ity on servers, rather than placing the entire app1ir~tion on all WO 95/W968 21~ 8 7 6 ~ PCT~S94/08785 clients, o~ t;n~s can u~lize the proc~-ss;~ power of the de~k~ while g ~ o~ points of control.

Protection Against Tam~ering. CG1~J- ~;nn.C have long l~ga,~led their S o~--~ g data as a major Co~lJG~ asset, and they protect that data with many Qqf~ q-rds. Increasingly, org~ ;nn~ are also viewing their ap~lirqtinn logic as a CGl~Glat~ asset that de3~ s equal protection. A co..~ may have developed a so~ ;rq~ m~ olir~ l~io~ l, an~sh~ leading approachfor P..1~,....9.~ g several b--c:~rsc steps, or an a~ ;r~ for al,p.~ g pay L~c.~ases. If the key CQ"~l~O~ Q
10 of these q~lirqtion~ are placed on ~cs~ ~ ...9r-~ s, they run the risk of n ;~d access, individual ~ g or CG.~.ate espionage.

Server-Based Control Points. It may also make sense to ~~-..;--;~ -- control points (e.g., a~ ,i- g e lY- ~ accol~nt ~ ,.U ~- ~C~ Q) on a server l,ec~
15 ~f ~ 1s are easier to ~",;~;Qt. ~ in a ~P-nt~li7~d ~.vuu ~ ~e -~ Ba~ ;m-;ng allows server-based control points to be developed as part of an overall aprliç~tir~n and e~ placed on a server. As d.~ l;r~l~C CQ~ e to evolve, it is easier to change r.-~-c ;.~ lity in a server ~lilio - than to install a new a~lir~;r~ .~o" on each dest 1 ~.
Fl~ribili~t. One of the i~h~ngll~ of a client-server enviro~ t is the ability toincl~ ly add both clients and servers. But these evol~ltinn~ry cl~ ges can .esenl problems for aprli~ tmc. ~d~itinn~l clients can alter usage p~l~...c as well as increase overall ~roc~ cc;.~g~ load. If more servers are added to the nGlwulL~ how 25 can 9~ qticmc take advantage of the ad~ ~l p vce~C~ power? Partitinning can offer a sol ltirm to these l,ot ~ 1 problems as well.

Sr~rpL.lfor ~'r~1~le E..vi,~ .ls. ~efiP~ ~ to Figure 9, an o~ ;n..'s co~ ul; ~g ~.vuot ~ may evolve from a two-tier to a three-tier e~vuu . .~e ~ Or,30 o~;"l;nn~ may be ~ ued to s.-~ull the same ~rFli~tinn at two sit_s, each witha dirr~ envu~ rt~l In these i ~ ~s, a de~elG~.--c,lt piog.~ .c~ may find hin-cPlf ~de~_loping an apFlir~tinn for the dirr~ e..vilo-. ~c ~l~; With a~ lir~ n partitinni~, the ~ p~ r can build and ~..A;.~ a single logical ap~ tinn ~3çfinitinn that ~u~ individual ~ sc-l- .~-s for each target ~Ivilot. ..

-- wo 95/04968 2 ~ 6 8 7 6 2 PCT/US94/08785 Support for Muced Em~ir.u,."~cnts. Another problem arises when an appli~tion site has dirr~.,nt classes of client ~n~rhinps. For e~ c, last year an olg~ )n may have ~llrchased hu~d~,ds of 38~based PCs on a five year ~lo~ n schP~ . Since then, the o~ ;o.- has been buying some llN~ w.. L~l;on.c.
5 Ideally, a new target al~pl~ could utilize both classes of ~ op machines, but this p~senls problPms How much of the a~l;~-l;o.~ should nm on the ~1~s~ lop? Ifthe devel~p-.. ~ plog.~ must s ,Co... --~t the least p~ rul m~rhinp~ they would und~ ze the UN~ w.~ L~ C to ~ cc--- ~ r, the PC. Referring to Figure 10, ~rp~ ti~n ~ g offers a solution to this problem. With 10 pa~i~t~ni~ a !cm~llPr por~on of the a~l;r~ can run on the PC and a larger portion on the W..-L~

Examples of Pa~t7c~ned Ap~l;r~ 0n~
To ilhlctr~t_ the power of partitinni~ this section A~ .. i~s four eY~mp'-15 ~ tir~n.~ All share a co~ n~ ch~rr^~-rict~ the appl;~at;nn logic (i.e., the pGlt;Gn developed by the y~og.~ e staf~ is spread over several m~hinP-s, e, ch with its own ~r1pli~tir~n pa~ un. These examples do not e.hn...,( the pQ-Q-Q;hilitiPs of arpli~ti~n p~l;l;r~ g. Nor do a~ lir~ c need to be as multifaceted as these PY~mp' -s to benefit from par~itinni~.
r~tomer Service A e~ service ,~pi~se .'~ in an c~ .;c utility co ~ gets a call from a ~V~ r co"~ g about a recent bill. The serv,ice ~ se~ e first needs to call up an ele~ 0l~ic copy of the ~ S~ 'S c~ It would help to have25 some analysis of the e~ 's overall usage ~~ Was this month P~ o."~l in the co-l~e ~ of previous ~n~ c? Were all bills for the area higher, ~4 1~ S refl~-cting a cold spell or some other factor that affected most people in the area?

Armed with this ;~r"...~ .., the service l~,pl~F,se-~ s the 30 ~ . ..-- 's ~ ;n.~ In the course of the co.~c~s~ , the 1~ ,e may s~gg~st ~ ; ... in one of the co..~ 's special ~io~,.-. .~ (e.g., subsidy for home inc~llAtion or the ability to average p~--.~ ls over the t~velve .~ of the - year.) The system should be able to pio-,.~l the ~ _ to ask the y~ ;Ally relevant ~ estionc and then ~,~casl the c~d benefit of each ~rogl~ll. The 35 ~..c~ .r may request a m~eting with the Cool~ ulor of these special programs, and the system should be able to notify the Coor~l;ndlor, pe~ rs via e-mail. The 216~762 ~v~ "l~r may l~uesl a tP~hniei~n~s visit to see if there is an energy leak on the propc.ly, and the system should aUow the representali~ to s-h-PA~lP such a service visit. The bill may be in error (e.g., service was not shut off when a c~sb~ r moved), and the system should allow the represcntali~ to correct that oversight S (after ~,.;lyillg its validity-). And, when the call is complete, the system should e~-u,-~P a letter to the u~r~u~r r co~r~ P the actions that have been agreed upon.

This ty~e of ~)pli~ ;nn l~q~s access to multiple data S~Jur~S and ~rplir~ti~n services that may ~;Q~ t A, Ihl~ghoslt the nctwu,lL ~efP.~Ti~ to Figure 10 11, ~ and billing data may be kept in atl RDBMS. The service afpn~
s-hPA~llP may also be kept in the RDBMS. The usage profile analyses and CO~15C~dliul~ yioE,~Il analyses may mn on a ~lilr~..,nl server. The appl~ needs to int~^e with both the e-mail system (to send ~ld;fi~ to the yiOg coo,~lillaloi) and the printer (to g~ h. the cQ..fi....-~ n letter.) This example could use as few as two partitions or as many as five in various impLP ..~ One pa~ n would run on the user's ~Ic ~t ' p, most probably witha er~phi~-~l user interface (GU~ to ~ll~lir~ the navigation among the many ;r~ n filn~tinn~ The fo-.--~ g of the ~ U-~--.'S billing and ^Xo~nt 20 ; .rO ~ could take place either on the de~t~p or on the data server. The analyses may be newly written for this ay~lir~l;n~; or they may h~ve been written p,~,~,iously, in which case the new ~pli~` .t;..~. needs to int~^e with them. These analyses could conce;~dbly run on the client or on the ~A1'~"~ seNer, but it may be p~ fe- ~,1- to run them on a ,~p~-~t seNer. Par~itionine allows the develo~
25 P~OL' ~ f r to yO~ having to decide where -they will run, and it gives the develo~ 1 p,op.~ ...,. the rl~dGIII to l~,locat~, them after the initial deplo~ nt.

Tnt~rfi ^ing With the e-mail system and the printer pose their own ch~llPnges.
Tbis example covers the simple case of 5~...A;.,~, instructions to these ~
30 ~st~.lls. (The next example covers the more complex case of l~i~lg and dis~ g mail.) The interfaces could run on the client, but this could tie up the client ~n^^hinP while invoking the e-mail and print ~SySt~ll and while ~3e~ling with any error c~n~liti~n~ that arise (e.g., se~ g the letter to a dirr~ t pnnter, or~e~li~ the e-mail mPsQage until the e-mail system is available). The ~lh~ e is to 35 place those ~llions of the appli~tion on the e-mail server or a pnnt server (or a single server where both int~ces run).

2l6876~

Par~itinning can simplify the b~ ling of this apFlir~tion (and the other examples) in three ways. First, it allows deve1op~ ,c~ Jrog~ P-~ to build the entire xp~lir~tinn witl-uul having to decide in advance where the various co...po..~P.-will mn. Secon~l, it allows develo~ cnl ~.~og,~ e-~ to use the same tool for allS al)pl;,`~ " Cu ll~)Q~f~ , as o~pos~ to using one tool to build the client portion and a dirr~ ~ tool (or nll~ltiphP tools) for the server CO~ f-~`;. Third, it z ~ h-s co " " ~ ~ir~tirmc among the ~ LiOI S of the ai.~lir~ mnning on the dil`r~,le.
machines.

Man~ac~urtng RPf~-~ri~ to Figure 12, this example models a very simple ...z...~r~r,hlri~lg ~rocess where a c~ machines a part from a raw metal block. The co '~
es the raw blocks from a ~ l;f ~, shapes them with a lathe and drills a hole acco~ to the buyer's spe~ifi~tir~n- Then the parts are taken to a testing m-^hi~lP
15 to verify that they co~ro ~ to the w~t~ ~f!~'S s~;r~ ;o~ before 1~;~ -g. Thetesting system ~ c~ ly rejects failed parts and alerts m~nag~ if the failure rate eYc~P~s a s~er;r~ ,.-~ her per hour. The alert should be p~ e.ll~tive: it should open a new window and display a mPs~e~ even if the user is running ~nothPr a~ ;nn at that time.
Refe~ri~ to ~o~ r example il~ h~h~ in Figure 13, this aprlir~ti~n involves bl~ i~ many co--~ t~. a ch;l~p:.~g and .~;~ing system, a user intP~r~ for a OCeSS e--g~ . to set the hthe and drill for the leq~ed mea~ule-~c!n~ an interface to the testing m.^^hinP to set the tolerance allo~ ce and reject the failed parts, and 2~ the ability to send an alert to the p-ûcess e~jnPP~r if the ~ilure rate is çY~Pscive.
These cQ...~ r~ uill run on dirr~..,n~ co-.-l-u~-s incl~ in_ ,enP~l business systems and shop floor mzrhinP controllers. RPr~ P to Figure 13, in one preferred e~ o~ f.~ a ~^^hinP control c~ uo~r conh~ls milling machines, ~Irillir~ mzrhinP.and COI~ 0~ ~rst~ lls on the shop floor. A qualiq control machine controls 30 ~ g .--z~ s and ~-r....-.~ or ;,.~.v~s tolerance analysis. A pro~ctir~n ~ rhinP ~ .J.~ ...,fi~ ri~ steps and pro~uctir~n sl~hP~l~llps. A l~.~C;~Pss services m~rhinP "~ S l~ceivil~g, in~enlo ~ and shi~ir~-. Each of these mz~hinp~s iS CQ"~Pr~ gell~er~ along wi~ an int~ for a process e-.g;--~, to provide an in~zr~tP~ ap~lir~ti~n co---l~o~P~ of service objects as needed to ~ mPnt each 35 fii nrtinn WO 95/04g68 ~! 1 6 8 7 6 ~ PCT/US94/08785 The ~ericir~n as to where the various portions of the ~r~lir~tir~n should run may be less proble .--l;rAl than with the c~c~ service eY~mpl- above. The i~t.o~^~e to the .~ .r~^tllring and testing m~rhinPs should probably run on ehe controllers for those ..~Ah;..~s. The user interfaces for the proccss ~g; ~ and the S slli~.ng/.~ ;vi,~g clerk need to run on their ~c~ 1~,~. Maybe there are one or two gP.nPr~l l,u:iiness sy~ s. The ch~llpnge of this ap~lir~inn is to build all the co~ ~n ~ as a fully ~.t,glaled appli~til~n- The goal is to ...;n;~ , the ~ mt ofcode needed to ~ r" the ..~ r-^1llring s~erifir~tinn~ from the ~ocess enginP-P,r's screen to the shop floor nl~Al~; .e-~ and to ~r~ h the other l,~ res fimrtionc.
10 Without p~!;';'~ , develo~ g~ wauld need to build this ~rI~lir~ n from the ground up as a collP~tinn of ;~depe~d~ l parts. They would probably usetools for bllil~li~ the GllI portion and the interfaces to the ~ali(Jus m~r,hinto.
controllers. And they would need to do their own ~.~on control and sorL~
CQnfi~ tion m~n~ge...fn~ Partiti~ning offers the ~ I;ve of b~ ing the entire 15 aprlir~tion as a single entity and then ~ qting the various p~lilions to the nodes where they would logically run.

One of the ~pecial ch~llP-n~es of this ~ q~ n is the alert to the ~iocess e ~g;~ 1 when the failure rate eYc~e~s Ihl~sllold. It involves either CQ~ QUS polling 20 of the testing ~ h;--f or being able to send a mP~ gP, from the testing m~hin~. to the e~;~-~r~, 's de~p. Sentling a mPs~ge is prefie~hlP from a ~.r~.. ~.. ~
o ~t If this type of mPss~ging c~r~hility is su~o.~d in the developlllcnl c.lvir~ ..r!n~ partiti~ni~ allows the alert to be built as though it would run on a single m^~hin~P and then physically ~, the initi~tinn of the alert from the display 25 on the user's de~.

Financial Services A 5e.~ ;rs broker ~enel~lly needs . ~-do... access to many dir~ types of data. R~o-f~ ng to Figure 14, when a .~ e~ calls, the broker may need to look up30 the cu~ - - 's ~-c~llnt in~o .~ . When they discuss the purchase of a new ~;ul;ly, the broker needs data from real time feeds showi,lg the current price and any up-to-the-minute news on the CG~ . The broker may also want to consult h r~. ;r~l data on the ~ . Before l~o-.---.f!nrl;-~ a p~ebase, the broker may want to consult a Portfolio Analysis model to see how this s~u~;lr would fit in with 35 the ~ r- 'S overall illV~ I slla~ r. And the broker may also want to consult an Invesl...~ Analysis model that co~ s this potential l.,~e;,l...~- ~I with ~lt~ tive 21~876~
~ WO 95/04968 PCT/US94/08785 s~ . If the ~ ~r wants to buy the sc~,w;ly, the broker needs to enter the trade and get ;~ 1;At* co~ n that the trade was suGc-Pscfillly eYec-utP~ at the agreed upon price. Or, if the market has moved higher in the .~A-~1;---e, the broker can then ask the cUstQmp-r if they want to yu~ ase the sc~,w;l~ at a higher price.
S After the trade has been eYP~ltPA~ the broker needs to initiate the pr~c~s~es to bill the c~ ....cr, update the ;vsto--.~--'s ~,lroli~ listing, and ;--el~-de the trade in the broker's cQmmiQCi~ n plan.

In the ~ A~ P, other users are running di~f~,e,ll ~rFlir~tinnc that access 10 much of the same ;,.rO.... ~ . for dirren~ yulyOS~S. ~ 1 analysts may be """-;lo-; .g cw~ stock prices, following-up on reaent news, and c~n~ cting in-depth analyses of hi~tnrirql data and daily ~ading volume. They may change their A~ on a stock and need to send ~mail to brokers whose clients have a pOS;I;~... in that particular stock. At the same time, the office m~n~ger may be15 .~ ;~ the trading volume of his office and analyzing the pro~lucti~-n of the various brokers.

As with the other examples, this zp~l;r~l;o~ lends itself very well to a ç.liPn~ s~l-..r alrk;t -ct~ ~,. The dirf~,~nl types of users may be ~ g di~ nl 20 ~trl lop ap~lir~tionc~ but they all may access a set of shared services. These services can inr~ e direct access to raw data (stock price quotes and feeds, news feuls, plus account and hictorirsll data), l~er~n~ reports (c-ust~,-.-r~ pu~lrolios~ daily broker productivity) and other ap~lir~tirm sel~ices (analytical models such as i.,~e~ nl analysis and l.o.lrolio analysis, ~;Ull~,~ cu~ ion algû-;~ .c, e-mail, access to25 back office ~;,t~""s which provide trading system, cust~ billing and broker cr.--- ..;c~:~.n ;~r~ n). Client sc.~ gives the brokerage house .~;-~-----.
fleYih;lity for developing, ...~ t~ g, and ;-~ ~"~ g these services, while the use of a GUI on the de~p can ~"~ r, the -end user's t~sk of navigating among the various se.~ices. Without p&~ , the various ap~l;r~ cu~ n~c would 30 need to be built in icol-~ . With ~ ;~, all 5el~ices could be built in a single devel-~....e.-l ~",vi,o-.-..e--' and s~s~u~"lly ~ll~tJ~d to the dirf~,le.~l m~rhinPs in the client se.~l en~i,o~

OrderÆntry Many ol~ Q;~;onC are using or investig~ting visually o~;~n~ t~rtive order-entry ~ .-,s. These S~ S have ~e ~t~ntial to give cllslon.e-~ greater WO 95/W968 ~ 7 ~ 2 PCTIUS94/08785 control in ~iry~lg exactly what they need, to in~l~ase c~lc~.. ~r c~qticf~cti~n~ to reduce the ------1~r of i,~ ~l orders, and to streqn~line the entire l,rocess of buying a product. This approach is under active develo~-.-F--.t by several retil sales o~ ;nn~ The ~lcsen~ l;on c n be used to develop new ways of ordering S goods, for ex~nple o~Cli~lg a new car. All of the ~ ppolling the t ' Au~o-gy is in place, and partitinnin~ would s,~ liry the develo~ of the a~plir~ An After looking at, and maybe driving, an available floor model or two of a certain car, a c~ sits down with the QqlP~-r~ at a PC to get an exact quote 10 and close the deal. As with most order/entry S~St~,.l,S, the a~lir~l;o.. would first qualify the buyer, acc~s~ g available services to checlc credit ratings and possibly bank bqlqn~s and emplo~l"~nt status. The buyer would point-and-c]ick on the model he wanted (or he could view mllltirlA models Qimllll~ .cly~ ,oo...;..g in to view one at a time when desired). He could CT~ ' with dirL,~ color s ~ -..PS and 15 ~letqili~ oFtionc which would be dispL~ on the screen in full color. The model under CQ~ ~ie~ ~;"" could be rot, ted for viewing from any angle. Fytp-r~ r opt; Anc~
such as mag wheels, would be di~ d as they were s~vlo~.d. The system could yro~id- an interior view for that model's coc~ from the driver's ~ oinl. The system would lJlo~llyl the ~-~ct~---.- . for non~l~y~ble optirnC (engine size, 20 ~A~ eer side air bag, t~ ded ~ 4), all while ,..~ g a running total price that could be di~ d wl,c~u~er ayy,opllate. When the spe~ifi~tinn is complete, the system could check the av~ ility s^hP~le and give the buyer a target delivery date. Then the order could be slJlJ-..;IJed electronically and m~nzlg~dclecllo, ically throl~ehol~t the ~ r-~.cblring ~rocess and the ~ :-,g cycle.
The same .... ~1~ can be used for other ~urchases such as the design and order of an office Ç.-.,.;h~-~, system or custom window ~s~---.bliPs for the home.
Pfi~Prrj~ to Figure 15, all have similar ~uu~ c~ for co--~ fn~ services:
d~U s~L.ns (such as on line catalog or .i"r~J~--.;",~ ro-.--A~;- .-), analytical30 sy~L."s or services (such as pricing, confi~ti~n cherlri~ or space re~luil~
;~f ----~ ), data s~ (such as C.JS~ data, ;~ g ~-co~lnt ;.. r~.. ";~n, credit check il~- ...zl;~ n or product ~ co-~ "A~ and an int~rf~re to producti~n s~r;,~ "s (such as srh~~ g~ ~"a.~"r~,-hlring~ sL~,g, and billing).

Iike the other e~ lPs, tllis type of ~r~ tion is well suited for client sel~er where apE~li~ti~n cQ-~ Q-Ienlc will be running on mllltiplP m~t~hines.

~ WO 9~/04968 2 1 1~ g ~ ~ 2 PCT/US94/08785 The ap~ tion may need to taL~c to dSlt~h~es~ imaging Sy~ lS, and credit ch~ ng services, while providing analytical services (pricing, confif~ tinn çl~rL ;i~g~ total weight, delivery date) and bl~cin~-ss services (order/entry, .. r~*l.i.,~, sl~i~ping, billing). The more facets to an apFlir~tion~ the more partiti~ning can help to reduce S develol"-lcnl complexity.

RVi~i~g Partihone~ 7plicntions wi~h Fort~
Forté is an advanced apFli~ti~n develop"lclll e~.v.lo~ n~ for bnilditl~ and 10 deploying partitir~n~ ~plir~ti~nc. It ;~ dcs a ~ based de~lo~..--.r~
e, ~ Q~ u~ complete with a GllI forms painter, an object-oriented 4GL, and an interactive deb~ . ~OE~ use this d~ o~---er~ Q~ e ~1 to create a logical appli~stinn dPr~ ;O~ ~at j~;ÇifiFS the desired r~--cl;o-ulity i~p~ Of any ~ç;r.c yh~cal C.lvilOf.-..- --~ Forté also ;~ des tools for ~cil~i-lg a t~rget 15 deplo~ nl enV~ fnl and g-, ~f-'~ a default parhitif)nin~ sch~ for ~e targetede.lv~o~-..f! nl In ~-lrlitirJn, Forté inr~ldes tools for m~n~in~ ~e par~ition~
ir-~;nn once it has been deployed. l~efe-.;-~ to Figure 16, ~ese tools ~ul~po~l a ~ree-phased develoç~ n~ cycle: ~P1;~ ;r~n der~ ; system ~,e~f.~;ol-; and A;Q~ t~ d ~l;.chil".~ n, Aprlirsti~)n ~ r~ may utilize G~lI~GL ;-~fn....AI;nn and 20 a l~l)os;~u~ of inr~ n about service objects. A debu~&Pr is hPIrful for ~is phase of ~r~ll deve~-ç-~ ' System ~,e~-.,.~l;ol- in~ des cQnfig~ ;-v~ and as well as code ge-~f ,~;nn. Deployment uses a ~ - ib.Jt ~ object nl~n~gP,r and ~,r.,. ,~ r~ or for system ~;c~ ;Qn to effec*vely distribute and utilize service objects.
Bu~ing a Logical ApFli~ntion De.finition The first step is ~if-r. .;-~ the logical ~l)pl;~er~ This step col~espo--ds to i-lg a client-les~denl a~ l;nn with other 4GL tools. But with For~, the logical ir~*r)n ~çfini*on can be par**nnp~ b~.l.Je~l to the devel~ f ~-~ phase.
lhe Physical Developmen~ Em~irv,."~,.l. The logical ~lir~*nn ~çfini*on is in[lf,~!n~ of any particular ~hysical deplo~ nl (..~iro~.-..f ~ thus giving deVelOp~llC~ll p~ f-'S COn~ P~blfÇ flPYihility for their physical develo~"-el-_n~iro..-..~.~l The inven*ive n Pthod l,fo~ides l- .~ nl portability across many 35 ~ IVil'~ , inrl--~ing the following:

WO 95/04968 ~16 8 ~ 6 2 PCT/US94/08785 Desl~top/Gl~I--Windows, M~rintn~h, Motif, ~S~t~l;nn M~n~g~r Server--UNlX (IBM, .~e~ent HP, & Sparc) and VMS (VAX & Alpha) Network--TCP/IP, DECnet, Novell, AppleTalk RDBMS Oracle, Sybase, Rdb, Ingres, TP Monitf-rs-ACMS, Fnri~u, Tuxedo Develop--.f ~-~ p~og.~ can use any ~ po~Ld e.. ~ to create the logical ~pl;r~ n ~efinitinn The a~p~ can be ~"~S~ deployed in an e.~ o~ with dil~ nl 1~.1~ . and sorh.~ CQnfiFll~ti~nc- For example, 10 develo~ pro~.~-..-.---- i may use PC clients tall~ng to a Sparc server for deve1r~....- ~-~ and then deploy on Mac clients tall~ng to VMS server. Portability and are both l~qu;~d for e.,~.ir~ Aep~rn~1Fn~. As client ~cr ~n~ co~ e to evolve, the s lAiti~n of new ~ rh -s and usage ~I~. ."c may l~U~ both a 1~ e of the ap~lirqti~n and a reh :~sting of ~pplica~;~"
Cc~ c onto dilf~.~.~ rhinP ~ u~ f~

An App1~cnt~'~n as a (:~ol1e~hon of Service Objects. As desç il~cd above, a Forté
ay~lir~ p~ l is d~pci~d as a cQllP~i(~n of service objects. Service objects may inrlllde~ but are not limited to: display services, d~hq~G access, int~-rfaces to 20 e~h----~l services (legacy ~."s, elec~u"ic feeds, e-mail), and o~,~ n s~ifir,b!-c nrsc ser~i;es. The service object ayyi~oacl~ allows an ~lg~ n to model its own l,--~ sc from the user's ~,-~l~c~

For ey~nlrl^~ to yroces_ a new order, the o.~ may need to verify the 25 c--~ -'s address and credit rating, check with inve.lt~ to make sure the desired product is available, send notice to ncc~llnting to initiate the billing cycle, and instruct ~ & to mail the product. Prior to cc--.l-vtj -~, people dealt with other people or with paper forms that other people h~n-llP~. The plOCeSS was laborious but rela~vely easy to colllyl~h~.ld. With the advent of co-~l-vt~ , the time to p~ocess an 30 order can be ~Ac~le- ~d, but it ~ S a data ;nL~h. cture. C.J~ --- r records are stored in a ~ ~" along with ~ccolmti~g~ lo~ and ~ g data. The job of the apF1ic-~ti~n pro~"-.. --~- is to provide a l,~pyillg bch.~.l the user intef~A-e (~.I.al.s a form on a co...l-~ screen) and the data infrastructure.

With pr~ l pro~ -.. -.. ;-~g, this .~.al)~ is usually aprlicati~ n spe~ fiA and can be con~plAY An order/entry aprli~tir~n~ for eY~mrlP, may call up the cllclul~l~r ~6~76~
record from the c~lctom~r ~qt-q-h-q-~e, check the cus~ fr credit ~-q-tq-hq~e, request the Lily on hand from the ~ e.~ h~, check to see that the ~lu~liLy on hand can ~u~l)oll the order, update the order l~q-t-q-hqce, and add a new entry into the sl,i~g .lqtqhq~.
s With a service object approach, the job of the yrog.~ ..c~ can he ~
R~ernng to Figures 17A and 17B, the RDBMS data infrastructure le.~ lS in place.
But now deve~ -..c--~ y~Og~ --..-..r--~ simply create a new service object that e~ a~ qo~-s the data i~r~c~ cture. For example, develop"lc~l y,o~.. -.--..~ - ~ nuy 10 create an i.,~ent~"~ service object, an order 1~OC4C' ~g service object, a c;l~s~--.-f-r ;, r,....~l;..n service object, and a Chi~ ~ service object. These can be controlled or guided through a c~nn~c~ order entry screen service object and a l~h h~ serviceobject.

This type of service object ;~r~ ucture can S~ ]i~ the develo~"~nl ,-'s job in several ways. First, it ~ ;r.~s the de~lo~ cn~ of new PpplirA~;O~c by allowing develo~ yl~og~ to reuse e~ g service objects.
A new ill~en~ apFlir~tion can be written that uses the i"~,nlo.~ service object developed orig1n~l1y for the order/entry aypli~ n. Secon~l~ it c;~ ir~ps aprlir~tirm 20 ...~ .u,.,~ by providing an ~ itinn~l layer of ~.<.ç~;~ n where bl~c;~cc rules can be ~nfor~ed while in0ll~ti~u aypli~-l;nn p~Og,~,lc from change. If the c~-..l~A-.
wants to decrease the ~mnllnt of il~ ~n~ ~ it keeps on hand, it can modify the service object instead of ~llodilyillg many individual programs. (By using code g~nG.~I;nn t~ ~ D!cgies, Forté .-.;.~ s the ~--r~ ----~-.re impact of ~nothPr 25 ~l~s~^ti~n layer.) Third, service objects ~ ,e3elll a m~~ ri7~1 view of an aprli~tin n that can both mirror the CQ...l~ 'S OlpA..;, ~;nn~l structure and provide a basis for par~itinni~.

The Forté approach to partitioni~ is not based on sF~ ~ out bUcinpss rules 30 or some other pre~çfine~ category of a~lir~ n fi-n~tinn~lity. Forté does not require develop-.-~ ,-;, to fit their appli~ s into one or several y~der~
molds. ~n~ , Forté allows develoy",c.,l y~O~ f,~S to model their applil~tinn e ~ O-~ f!n~ in the way that makes most sense to them. No structured methodologyis 14uil~d to build Forté applir~linnc.

WO 95/04g68 21~8 ~ ~ PCT/US94/08785 Forté uses the develo~ n~ o~.~.. f r~efin~ service objects as the basis for partitir~ni~lg. Each partition i~ r~ es one or more service objects. All service objects will be kept intact within a partition. No service objects will be divided among partitions. An applir~tinn may have three service objects or it may have S thirty. The greater the ..~ of service objects, the greater the --~ hf r of possible ~",-IIA~ C forpartitinn~ ov~s.

Forté Objects. Forté is ~f~ ierl~ to deliver the 1,~ i of object-o- ;~
~.o~.~-..-..;-~g without l~uil-ng a total c~ ' to object technologies. Users do 10 not need to store their data in an object ~ hq~. Nor do they need to use C+ + Sm^~lltql~ or other object-oriented l~ngu-qges~ ~n~t^3~, Forté ~v~ides de~loL.nf--l pro~;.,..--..~-~ with a foIms-based en~ c~t for c,cating classes and a l,r~ lly r-;---~14GLforwritingtheir.

Under the covers, Forté is object o.;f!nh~ at is written in C++ and vu~po,~
object n- ;f .~ ;rm with e-~ v-~lqtion~ kP.. i1~.~re, and pol~lu~ .) Forté objects are reusable across ap~ q~tir~nS~ and de~e1o~ t P1`~KJ~ r~ ~ can add or change ~ ~f 11~$ wilLuul ~ the object. Forté objects pass .--es~a~.rs arnong thpm~lves. (Forté provides its own peer-to-peer meS~j~ system for 20 co--.-..----;r~tin~ among Forté p~liolls. It can also use either an RPC ~Remote ~1U1~ C l1) or a CORBA ((~-~------o-~ Object ~P~est Broker A.~ ;t c1-i~e) style mPs~a~ -S~- l for Cc"" ~ `, ti ~ with ~ t - .-5'1 objects and services.

Forté vu~l,oltv the . lw.lion and ,..~ ..1qti~n of both GUI-based objects and 25 ~enerq1 applirqti~n objects. Most G~lI tools v.l~)o,l GUI-based objects that are ~,csP---~ as icons on a screen. Not all of these tools, I~ er, Sl1~O1~ the creation of apF1ir?ti~n objects, such as an .n.enloly ærvice, that are apr1ir~ti~n logic services and not just y,~se-~ ;on services. Forté ~ ~ t these arr1ir~tir~n services which are crucial to ~rF1ir~tion par~itir~ni~. When an a~ is partitinnPA, these 30 ~ ". services can be located on a server where they may be -~c~ c~ by many users of the same d~ and/or by dilE~ rF1iC~ti~nc- Forté is a developrn~
~,.vin"..,~ for b~ ng both cl~ent appli~ ions and server ~Irpl;cnrtQns. T~ds is a major dep~ from ~tlitinn~1 apF1iratinn deve1o~ tools.

~ order to ,.~pl)oll the deve1~-~ of aprlir~titm objects that can function as servers, Forté PYtPnfle~ its object model in a few key areas. Most tools for building -- WO 9~/04968 216 8 7 6 2 PCT/US94/08785 client q~1irpti~n~ have no notion of slla~ability be~ se the ap~ *on code is nP~ to run on a single user client ~-,A^l-;--r. These Pr~lirqtic~nc rely on a server, such as an RDBMS, to handle such multi-user issues as conc~l~rency control and trPn~^tinn.c. Forté built cQ~ ;y control and trqn~qrtinn~ into its object model so S that server ~rElirqtinnc can y~Yide the same style of shareability as an RDBMS, even where a portion of the Pr~lirqtinn does not use an RDBMS.

The So~ware Deve~ l E~ rv,~ Forté p~oYides a set of visually Q~iPn~^~ w.. kl.~S for b~ i~ an ap~lirqtion~ There is a Windows Wo~ hop for 10 ~lecigr~ing sc~ s with a point-and-click style in~rf~r~ that creates screen widgets from a palette of s~l~d widget types. There is a Object W~ np that provides a form for creating ar~lirqtinn classes and other P~ lir-q-tinn c~ . There is a Method Wo~L~hnp for writing ..-~ll-~c in the Forté high level lqn~agP~. Since the Forté lqn~lqge ~.lpp~lt~ rev~ql-hP. ~ ;nn objects, it can be ~ ly ~es-- il.e~
15 as an object-o-;e-~ l 4GL.

The Forté lqn~lq,gP, inco.~ s constructs from three types of lqn~lqgçs. It inc~ olates event loop prog,u""".~,g, first pop~ q-ri7~1 by IIy~r~d and s!l~s~e-.lly l)tili7p.d by most GUI tools to deal with the un~ ~irt-q-hlP- . rrival of 20 non s_~ue 1;~l user actions such as chooc;~E a menu item from a list of several posQ;~lp- choices. Forté uses event loop p~ to handle events that ori~jnqtP.
on the user's screen and also to handle events that are i~ d by the system and by non S~ based apFlir~q~tion co~ o--cnL.~ (such . s sPnAing an alert from a testing mqrhine on the .~,a,luracturing floor to the process control ç~jnP~e~s wo~ n.) 25 The Forté hn~l~ge also inrl~des procedural prog~u.""~,g constructs found in most third and fourth ee.~f.~ n lqn~l~qges for hqnAli-u the flow of control (if....then...else) and for crea~ng vq~iqhl~s and eAl)~s~ol s (1 + 1). ~ ~AAi*on~
Porté illc~.~ .t~ s star~rd SQL for s r'c~-c~ ~g an RDBMS. By incG ~u~ g sku~ SQL into the develol,lllcnl lqnguqge, Forté can ~.~o~ide RDBMS portability 30 by ~a~ g SQL calls into ..ulllcroLs SQL ~ lpctc and by g~.~r.~ p vendor S~--;r~.
stored p~ cs for o~ RDBMS ~- r~ . Forté also provides an e~-tive 4GL debugger (that was built using ~e Forté 4GL.) RPf~Prrir~g to Figure 18, all develop--~.-l work is stored in the Forté
35 l~OS IOJ~. ~The Forté dev~P1o~""~"l e.-vi~..c-~ inr~ les a blo..~r to view the previously created cl~ses, their mçth~s, and ~ ~s so they can be reused or WO 95/04g68 PCT/US94/08785 2JL68~62 easily --~;rPA for new ~rF1icqti~nc.) The le~ 'J ,~/ stores the ~lefinitir.n of all jr~ti~n service objects in an envil~o~ ' neutral form.

The l~Oc;lO,~ ~ovides several filnrtinnc It ~ Olt~ t_am develo~l..enl with S check out/check in so that several deve~ p~ rs can be W~ki.lg on dirr~ t parts of the qrp1ir~ti~ n at the same time. It ~.-p~o,t~ ve~ ning and c~nfi~l~tirn ~r~nage...~ to f~rilit~te builds of complete apF1irqtir,n~. It stores the ~efiniti~m of that target deplo~ cnL e~ 1 And it stores each par~itinning sc1.r ..~ for each c.l~ r ~-Genera~inB a Pa~itioned Applicntion Once an qrFlirqtinn has been ~efin~, the deve~ ,o .~ cr can test any par~itirmin~ sc1-r~ by cim~ ting the deplc,~r~l~n~ en~ 1 in the developll~nL ~n~o~.. e-~ At this time the a n can be l~ n~ without ~yillg the ~rlFlir~tinn ~efinitinn The ~ lir~tinn can be l~l;l;n~l at other times as well.

The first step in the system ge-~f."t;nn phase is to define the target deploy.llcn 20 e,lvil~o-.-~ What are the clients (Windows, Mac and/or Moti~, what are the servers, l~lwG~ ~s? This ;~f~ t;nn is stored in the l~c~ for use in the p~l;l;lJ..;ng process.

The second step is the default partitinni~ of the ~ l;ol-. When the 25 partitinning co...-.~ is given, Forté l~ tl;~_S the sperifi~tinn of the target deplU,~lllfnl e~lVi~O~ and analyzes the logic of the a~l;r_l;nt~ ~efinition It s each service object and notes ~Lf ~r it was ~e.;g~ to be shared or to be ~^r~ss~d ex~ ely by a single user. If it was ~esig~ed for exclusive use (such asthe set of y~s~ l;nn services), Forté will place that object in a client partition. If it 30 was ~esi~ for shared use, it is a Ca-~ t for being moved to a server. Some service objects are ~Ccor ~ with an eYt~ ~sou-~. For e~ D, an inte~ce to access an RDBMS is ~cs~i~led with the target RDBMS and its physical loc~tinn. Ant~re to a legacy system is ~Cc~ori~tl~ with that system and its physical loc~tinn.
Other access services may inr~ 1e real time feeds such as a stock ticker or plocess 35 moi.;ll~. ;-.g feed. In each case of access to an eYtern~1 service, Forté will m-~ke a default ~ccig,.. ~ of the partition to run on the node where the int~ ce is located, as ~efinP~ in the repoitory. There may be a ,.-~ er of other shared service objects that are not d~l~clly ~csoc~ d with an e h ~ sJuree. These may inC~ e co~ n~1 or analytical services, and they may inrl-l(1e a set of business rules that e~o ~ an o~ t;n~'s po~ P-s. These shared l,~-c:~ ss services may access other S service objects that, in turn, pro~;de raw data from a ~ h~ or real time feed.These shared services may also access other Cl~iCeS for coo~ 1;on lJulyoses. Inthe order/entry ~ ~~ above, the order ~rocess service object r^csC.~ both the n~ly service and the d~i~-g service as weU as acc~ g the ~ h~ d~clly.
RP~P.1T;~ to Figure l9, where there is a set of service objects that do not dil~ctly 10 access an e-~ ce, Forté wiU ~-It ---l~l to ~ catP those service objects evenly across aU Ihe available ha~ servers as ~ ~ in the target c~nfi~ tinn.

This default partitinning approach may not produce the ideal partitinning 15 sc~ , but it is a Skulillg point. Forté also provides tools for ~lrO ~ c~
.~o,.;~ g and lcp~;~;oni~ to aUow for a m~nll~l o~ of the default partitinni~ S~ r...,~,.

The use of an object model for devel~enl helps to idenliÇy the logical0 bo~n~q-;es for parhtioni~. Since each service object ;~c'~ -s a ~o~ lly large be~ of objects at lu~lL ~le, each with its own .~. !l.odst the default partitinning roc~ss must identify aU the possible .~.e~l~ods that can be invoked in each partition.
The system must then locate those ...~Il.~c in that p~LLo,~ so they can be ~rcessed when called. Parhtir~ni~ wiU not work effici~Pntly if these mP~thods need to be25 ~ tCI~ at lu-~ --c from ~ Cr node.

After creating the a~ rql; ~ ~Ll;ol s, Forté moves the server ~LLons to the target servers in the e.lvilo~ Pf~ g to Figures 20 and 21, Forté refers to the t~rget c~nfi~l~tion definition to see what l~lwul~ are available and 30 ~ A11Y sets up the a~pro~lldt~ n~lwull~ co~ ;c-~;n~C to send mPs~ges b~t~ each set of nodes. Each Forté server may use dirf~ nl cQ~ ;c~Atinn plûtocols to cC~",.".~ir~te with diff.,l~nl servers.

Each par~tion is serviced by a cQl1pctinn of Forté system services that m~n~ge 35 c~.. "~ ;r~tinnc arnong partitions, mess~ge traffic within each par~tion and the 2~68762 p~Qcin~ of m-o.sc~E~es to remote objects. These system services m~n~e all the apI~lir~tir~n service objects on each node.

At this point in the system ~,e ~ n phase, the paItitir)n~ apFlir~ti~n can be S run int~,yl~ h~ly. Iike most 4GLs on the m~rl~t Forté Co~ ,tS 4GL source code into a pseudo-code that eYIo-cut~s ll~vu~,h the Forté l~t~ly~ . Since Forté can create shared ~p~!lir~ n service objects, these objects are stored in the l~JO~ J ,~, and ~t~ yl~t;~ eYr~vl;r-~ involves l~pOc ~ look-ups. In ~ltlitinn, int~_lyl~v~
e~cc~ es ~c~eC~ the RDBMS(s) with dynamic SQL. Whereas most of the0 ~ liti~n~l 4GLs use this ~yy~oach both for de.c~ and deployrnent, Forté only i~S interpretive mode for de~.~lop~ -n~ For pro~uctir~n ay~ c~ Forté offers a code ee~f-~;on option to 1I~C~ y -~1~

Each Forté p~ulil;on can be deployed for pro~c-tinn either as an nt~,ly et~d 15 ~ l;o,. or as a c~n~pil~ p~liGn. Since the ~eriQ;on to run ~--t~y~ ly or compi1ed can made on a y~liliull by pa,lil;on basis, it is pos-Q;~1e to h~ve a mixed env~ -f~1 of~ y~,liv~ and cQn~riled p~Ll;ons to ~ yyo l, for; ~'-, a ~1ec~ S~l~yGll r.. ~;n~ as part of a larger ap~ r~l;nn also co~ g some tr~n.Q~cfir-n y~O~
Forté offers two code en ,..I;.~n ~h; tf g;r-s to s.lyywl cr~n~Fil~ apFlir~ti~nc.
The first takes the Forté pseudo-code and runs its through a ee ~ 0~ to produce dard C++ code for each yaltiliOl . This C++ code is then con~ril~A witn tne local C+ + con~ril~-~ for that particular node. The res~lt~ hin~ code provides a 25 p.,- ru .~nr4 benefit over most applir~*~nQ created vith a 4GL ~at run in~lyrelively during deplo~I"cnl. During code ~en~ , Forté resolves aU I~,feiences to the ~o~lu.~ so the .~-"li-"~ system does not need to incur the ~,- fi -.-~--c4 penalty of repository look-ups.

The second code ee~G~t;nn ~hat~ ,s a set ûf RDBMS sI)ecific e~ f ~ that produce û~ ; ~ access for each s.~p~ol~d RDBMS. For eY~mr1~, the code ~,e--F,-~or for Sybase produces T,. ~ QL while the code e~onp~tor for Oracle 7 produces PL/SQL. ~ each case, the code ~ ..r~ tor takes the RDBMS-neutral definitirn of ~l~t,.l~ access and e~nf. ~o~s the a~l~ro~late s~ategy 35 for acce-QQ;~ the RDBMS with an op!; -;~ ye~r~ 4 Sllate~

-- WO 95/04g68 ~ 7 6 2 PCT/US94/08785 Managing a Partitioned Appl1cn~en Following system gcnP~l;r~n~ the ap~lir~tir~n is ready for deployrnent. The first step is to install the client partition(s) on the target de-~l lop m~r-hin~ps. The ap~lir~tir~n may call for a n~ixed t,..~ of PCs and Macs. In that case, Forté
5 would produce a PC ~on of the client ~L~n and a Mac version. The system - l...;n.ch~ r would then need to install the a~ o~idte partition on each ~&rl~lop m-^,hinP..

~nQt~ tion also offers the G~ul~ for re~lir~tp~d partitions. There are two 10 l~asolls for i~Qt~lli~ reFlir~tpJ~ liLons. The first is load ~ ncing. For s ~in an SMP (S~ .. h;C Multi 1?~OC~Q- -r) en~u~ nt~ it might make sense to run the RDBMS engine on more than one ~ ssor to i~ pO.l a greater load. In ~is case, the RDBMS access partition should run on each node where an RDBMS engine is locqtp~ Forté ;.~Il)pu ts the le~l;rAt;r~ of this RDBMS access partition and 15 provides a router to aUow multiple RDBMS e~ s to service the next RDBMS
Jei,~ in the ap~lirstinn queue. The other reason for re~lir~tinn is to provide backup in the event of a node ~ilure. Dich il .~ut~ e.-~uo ~ e~c inc.~ the probability that one node in the system wiU be down at any given point in time. If that node is particularly crucial, it may be a~lo~.~te to have a back-up node. For 20 example, a node may provide a key analytical service or image for the user. In these cases it is po~ihlP to define a ~ l;r~led ~lilion as an glt~ t~ node that can be?,r~ in the event that the p.~ node is unavailable. Forté also provides a router that can access such a backup node.

It has already been mPnfi~nP~l that the ~;`h ;~ nlil--e en~i,o-.-.. ent must ~ unde co~ ;rstionC among the ~l~pl~ partitions. This concept is foreign to most deve~ tools. Tr~itinnql tools rely on the RDBMS to provide the cci~ r~tinn~ .h.~,..n client and server, thus mski~ the RDBMS an esconl;~
part of every s~ljrqtion Fort~ does not g~ that an RDBMS is part of the 30 s~lirqtinn, and even if it is, Forté can sngmPnt the co~ ;rstinnc poscihilitips offered by RDBMSs. This can be esperiqlly ,..~o.t~ when co~ ;r~qting with non-RDBMS servers. Forté provides co...~ ;r~qtionc among applic-qtion partitionswith its own ~ J~1 mPsQagi~ system. The mes~gjng system is c~qble of ~c~:.,g meScq~gPs among objects within a p_rtition. It is _lso capable of psc~ing 35 mPccq~es beh.~-- objects located in dirr~.~nl partitions. Cross-node mPs~q,gjng is ccon~rli~hed with the help of proxy objects that are loc. ted in the local p. rtition. If WO 95/04g68 PCT/US94/08785 ~lS8762 an object in the client partition needs to send a mPc~qgP~ to an object in the server partition, the partitirming algo~ilL-I, must place a proxy for the server object in the client partition. This strategy en~hlPs aU client-resident objects to behave as though all server objects were also located on the client. And when a client object sends a S mP~agÇ to a server object, the proxy i lt,.ce~t~ the mPs~gP and ~ S it to the node where the physical server object is locqtP~l. This shdt~g~ of using ~o~s el;~ s the need to send large objects over the nelwulL, and it allows an ir-~;o-- to behave the same regardless of where the l)h~ical objects are located.
This is a critical aspect of a sw~r~sfi~l ap~ ;o~ pa.~ g sQl~l*nn Once a .1;-~. jb~ft~ 'qtinn has been deployed, it is very hPlI-fi-l to be able to mqna~Ç it as a single entity. This means being able to start and stop ~liliwLs from a single mqnq~e~...f.~ interface. It also means being able to .~ o ~lru-...~-.re for the ~pplir~ n as a whole, in r1~itir~n to troubl~hoo~ g in the event of 15 ~.ro-~ e problPmc. Where is the time being spent? In co--- .~ qtirnc? Inside a particular pa~ iûn? This ;--fo---~ allows the system a~ h~fOI' to spot .r.. ~ otll~u~ by ~ g the a~ lir~ n as a whole. RPfP~ ng to Figure 22, Forté ~vvides an ~llviro~.-..r-~1 M~nagPr interface to provide this inro-...~;nn for the .i;,~l. ;k~ltr~ ap~ tion as a whole from a single user in re. ru-~"~r~ n~ p may suggest a dil~ ,nl partitir~ninf~ P.
RPre~ E to figure 23, Forté provides a drag-and-drop style ~ ;l;nning intP~
to ~lily tbis proc~ss. The ~r~1ir~tinn ar~ lor can-view a SC~ AI;c diSIg~m of the current partition sr1-~ , and can intP,~r^t d~clly with that sç1u--..A1;c. Along 25 the left hand side i. d~played a listing of all partitions and the service object.
i.~h-d~P~ in each ~ n. To move a service object from one partition to A~o!1~Fr, the ~ ;Q~ .tnr can e ~f,C~ a simple drag-and-drop ope-~ i~wise, the lor can move a p~uLLon from one node in the s.1~ ;c to 5~0t1~f,r by ~Pgi~-and~o~ ng the ~ Lion name to the desired node. T}~ tP~r~ can also 30 be used to drag a p~lio~ name from the list on the left to a second node on the s~ l;c in order to set up a ~ a~ p&~ ;Gn.

Once the new par~itionin~ srl-~ has been d~P-finPd, the ^~lminictrator can eYec~tP a ccs-.--.~n~l to g~nf'~ a new ~ e scl~ for the same deployme.lt 35 ~.~VilO..-..~ Both partitinning sc-1~ s are stored in the l~O~;Iu- ~ for ...~........

--WO 95/04968 ~ 1 6 8 7 6 ~ PCT/US94/08785 flPYihi1ity. The new par~itinning scl~e ..~- then needs to be in.ct~l1~ for the changeover.

Par~itinning offers an easy way to build ~ ap~ tinnc~ to partition S the ;,l.ilir~l;nnc for a given deplc,~ n~ e.lvllo ~ 1, to ~ ;n;~ f all apr~ ti~n CCS~ Q~ as a single entity, and to f~pallilion the apFli-~tion as problems arise or as ~u--~.llcnls CQ~ e to evolve. ~ n partiti~ni~ is an ~ l sll~gy for c ~ the client- erver alchit~ ~t~ , for ,.,.~.t..~g the ~le .A~I~S of mic~i- n critical apr1i- ~ti.~nc that can span the e.lt,~.
A g~PnP,~1 ~esc ;l ~ of the device and --f-!h~ of using the ~,c~nl invention as well as a ple~f~d embo~ nl of the p,~,sclll L~c~l;on has been set forth above.
One skilled in the art will iecogl~ and be able tO p~rfir~ many ch~ngP,s in many~cpectc of the device and ~ !1-o~ ~es~ ~ ih~ above, incl~ ing v ~ which i~ll 15 within the ~ching,c of this invention. The spirit and scope of the invention should be liTnited only as set forth in the claims which follow.

Claims (51)

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. A method of using a computer to design an application program to be executed on at least two interconnected computers, selected from at least two classes of computers, said method comprising selecting a first class of computers comprising a first plurality of computers, each of distinct types, selecting a second class of computers comprising a second plurality of computers, each of distinct types, any one of said second plurality of computers interconnectable with any one of said first plurality of computers, and preparing a logical application definition for an application program, said logical application definition comprising defining a first service object, defining a second service object, and defining a third service object, such that each of said first, second and third service objects can communicate with at least one of the other said service objects, said first service object capable of execution on substantially any one of said first plurality of computers, said second service object capable of execution on substantially any one of said second plurality of computers, said third service object capable of execution on substantially any one of said first plurality of computers and also capable of execution on substantially any one of said second plurality of computers, but without selecting, at the time of preparing the logical application definition, a specific one of said first plurality of computers on which to execute said first service object, a specific one of said second plurality of computers on which to execute said second service object, or a specific one of said first plurality of computers or a specific one of said second plurality of computers on which to execute said third service object.

2. A method of loading an application program comprising designing an application program using the method of claim 1 and further comprising providing a heterogeneous environment in which said application can execute, said heterogeneous environment comprising a first computer selected from said first class of computers a,nd a second computer selected from said second class of computers, said second computer interconnected with said first computer, said second computer of a different type than said first computer, selecting said heterogeneous environment, loading said first service object on said first computer, loading said second service object on said second computer, and loading said third service object on said first computer.

3. A method of executing an application program comprising loading an application program using the method of claim 2 and further comprising executing each of said first, second and third service objects to execute said application program.

4. The method of claim 1 of designing an application program further comprising defining a first means for message transfer for passing a message to transfer information between said first service object and said second service object.

5. The method of claim 1 of designing an application program further comprising defining a first service object request broker, capable of execution on substantially any one of said second plurality of computers, connectable to and in communication with said first service object for relaying communications to and from said first service object.

6. The method of claim 5 of designing an application program further comprising defining a second service object request broker, capable of execution on substantially any one of said first plurality of computers, connectable to and in communication with said second service object for relaying communications to and from said second service object.

7. The method of claim 6 of designing an application program further comprising defining a second means for message transfer for passing a first message from said second or said third service object to said first service object request broker, then forwarding a second, corresponding message to said first service object.

8. The method of claim 7 of designing an application program further comprising defining a means for asynchronously passing a message from one of said second or third service objects to said first service object by sending a message to said first service object request broker, storing said message, then forwarding said message to said first service object.

9. The method of claim 8 of designing an application program further comprising defining said first, second and third service object request brokers and communications between respective ones of said first, second and third service objects and said first, second and third service object request brokers as needed to allow said application program to rim as if each of said first, second and third service objects were in a single physical address space.

10. The method of claim 1 of designing an application program wherein said first class of computers supports a user interface.

11. The method of claim 1 of designing an application program wherein said first class of computers comprises one or more computers selected from the group consisting of a workstation, a personal computer, a laptop computer, a palmtop computer and a personal digital assistant.

12. The method of claim 1 of designing an application program wherein a first computer in said second class of computers comprises a server.

13. The method of claim 11 of designing an application program wherein said second class of computers comprises one or more computers selected from the group consisting of a mainframe, a minicomputer, a superminicomputer, a workstation and a personal computer.

14. A method of loading an application program on interconnected computers selected from at least two classes of computers, said method comprising selecting a first class of computers comprising a first plurality of computers, each of distinct types, selecting a second class of computers comprising a second plurality of computers, each of distinct types, any one of said second plurality of computers interconnectable with any one of said first plurality of computers, and preparing a logical application definition for an .application program, said logical application definition comprising a first service object, a second service object, and a third service object, such that each of said first, second and third service objects can communicate with at least one of the other said service objects, said first service object capable of execution on substantially any one of said first plurality of computers, said second service object capable of execution on substantially any one of said second plurality of computers, said third service object capable of execution on substantially any one of said first plurality of computers and also capable of execution on substantially any one of said second plurality of computers, but without selecting, at the time of preparing the logical application definition, a specific one of said first plurality of computers on which to execute said first service object, a specific one of said second plurality of computers on which to execute said second service object, or a specific one of said first plurality of computers or a specific one of said second plurality of computers on which to execute said third service object, then providing a plurality of heterogeneous environments in each of which said application can execute independently, each heterogeneous environment comprising a first computer for said heterogeneous environment, selected from said first plurality of computers and a second computer for said heterogeneous environment, selected from said second plurality of computers and interconnected with said first computer for said heterogeneous environment, selecting a first heterogeneous environment of said plurality of heterogeneous environments, loading said first service object on said first computer of said first heterogeneous environment, loading said second service object on said second computer of said first heterogeneous environment, and selectively loading said third service object on one of said first computer or said second computer of said first heterogeneous environment, and selecting a second heterogeneous environment of said plurality of heterogeneous environments, loading said first service object on said first computer of said second heterogeneous environment, loading said second service object on said second computer of said second heterogeneous environment, and selectively loading said third service object on one ,of said first computer or said second computer of said second heterogeneous environment, independent of the selective loading of the third service object in said first heterogeneous environment.

15. The method of claim 14 of executing an application program further comprising loading said third service object on said first computer of said and, for each other object, selecting the other object for execution on one of said first heterogeneous environment.

16. The method of claim 15 of executing an application program further comprising moving said third service object from said first computer to said second computer of said first heterogeneous environment.

17. The method of claim 14 of executing an application program further comprising selecting said third service object to execute on said first computer in said first heterogeneous environment and selecting said third service object to execute on said second computer in said second heterogeneous environment without changing the overall operation of said application program in said first compared to said second heterogeneous environments.

18. The method of claim 3 of executing an application program further comprising replicating said third service object as a duplicate third service object and loading said duplicate third service object for execution on said second computer.

19. The method of claim 3 of executing an application program further comprising executing both said third service object and said duplicate third service object to provide load balancing.

20. The method of claim 3 of executing an application program further comprising using said third service object and said duplicate third service object to provide fault tolerance.

21. The method of claim 1 of designing an application program wherein said first and said second computers are respectively a first CPU and a second CPU tightly coupled to said first CPU.

22. The method of claim 1 of designing an application program wherein said first computer is a client and said second computer is a server.

23. The method of claim 1 of designing an application program wherein said first computer is a first server and said second computer is a second server.

16. The method of claim 15 of executing an application program further comprising moving said third service object from said first computer to said second computer of said first heterogeneous environment.

17. The method of claim 14 of executing an application program further comprising selecting said third service object to execute on said first computer in said first heterogeneous environment and selecting said third service object to execute on said second computer in said second heterogeneous environment without changing the overall operation of said application program in said first compared to said second heterogeneous environments.

18, The method of claim 3 of executing an application program further comprising replicating said third service object as a duplicate third service object and loading said duplicate third service object for execution on said second computer.

19. The method of claim 3 of executing an application program further comprising executing both said third service object and said duplicate third service, object to provide load balancing.

20. The method of claim 3 of executing an application program further comprising using said third service object and said duplicate third service object to provide fault tolerance.

21. The method of claim 1 of designing an application program wherein said first and said second computers are respectively a first CPU and a second CPU tightly coupled to said first CPU.

22. The method of claim 1 of designing an application program wherein said first computer is a client and said second computer is a server.

23. The method of claim 1 of designing an application program wherein said first computer is a first server and said second computer is a second server.

24. The method of claim 3 of executing an application program further comprising deactivating said third service object after said duplicate third service object begins execution.

25. The method of claim 3 of executing an application program further comprising moving said third service object from 'said first computer to said second computer.

26. The method of claim 3 of executing an application program further comprising replicating said third service object on said second computer.

27. A method of loading an application program comprising designing an application program using the method of claim 1 and further comprising providing a heterogeneous environment in which said application can execute, said heterogeneous environment comprising a first computer selected from said first class of computers and a second computer selected from said second class of computers, said second computer interconnected with said first computer, said second computer of a different type than said first computer, selecting said heterogeneous environment, loading said first service object on said first computer, loading said second service object on said second computer, and selectively loading said third service object on one of either said first computer or said second computer.

28. A method of executing an application program comprising loading an application program using the method of claim 31 and further comprising executing each of said first, second and third service objects to execute said application program.

29. The method of claim 1 of designing an application program further comprising defining a third service object request broker, capable of execution on substantially any one of said first plurality of computers and also capable of execution on substantially any one of said second plurality of computers, said third object request broker connectable to and in communication with said third service object for relaying communications to and from said third service object.

30. A method of executing an application program comprising loading an application program using the method of claim 14 and further comprising executing each of said first, second and third service objects to execute said application program in said first heterogeneous environment.

31. A method of executing an application program comprising loading an application program using the method of claim 14 and further comprising executing each of said first, second and third service objects to execute said application program in said second heterogeneous environment.

32. A method of using a computer to execute an application program on at least two interconnected computers, selected from at least two classes of computers, said method comprising selecting a first class of computers comprising a first plurality of computers, each of distinct types, selecting a second class of computers comprising a second plurality of computers, each of distinct types, any one of said second plurality of computers interconnectable with any one of said first plurality of computers, and preparing a logical application definition for an application program, said logical application definition comprising defining a first service object, defining a second service object, and defining a third service object, such that each of said first, second and third service objects can communicate with at least one of the other said service objects, said first service object capable of execution on substantially any one of said first plurality of computers.

said second service object capable of execution on substantially any one of said second plurality of computers, said third service object capable of execution on substantially any one of said first plurality of computers and also capable of execution on substantially any one of said second plurality of computers, but without selecting, at the time of preparing the logical application definition, a specific one of said first plurality of computers on which to execute said first service object, a specific one of said second plurality of computers on which to execute said second service object, or a specific one of said first plurality of computers or a specific one of said second plurality of computers on which to execute said third service object, providing a heterogeneous environment in which said application can execute, said heterogeneous environment comprising a first computer selected from said first class of computers and a second computer selected from said second class of computers, said second computer interconnected with said first computer, said second computer of a different type than said first computer, selecting said heterogeneous environment, loading said first service object on said first computer, loading said second service object on said second computer, and loading said third service object on said first computer, then executing each of said first, second and third service objects to execute said application program.

33. The method of claim 32 of executing an application program further comprising moving said third service object from said first computer to said second computer.

34. The method of claim 32 of executing an application program further comprising replicating said third service object on said second computer.

35. The method of claim 32 of executing an application program further comprising not loading said third service object on said first computer, but instead selectively loading said third service object on one of either said first computer or said second computer,

36. The method of claim 32 of executing an application program wherein said first class of computers comprises one or mere computers selected from the group consisting of a workstation. a personal computer, a laptop computer, a palmtop computer and a personal digital assistant.

37. The method of claim 32 of executing an application program wherein said second class of computers comprises one or more computers selected from the group consisting of a mainframe, a minicomputer, a superminicomputer, a workstation and a personal computer.

38. The method of claim 32 of executing an application program wherein said first computer is a client and said second computer is a server.

39. The method of claim 32 of executing an application program further comprising defining a first means for message transfer for passing a message to transfer information between said first service object and said second service object.

40. The method of claim 39 of executing an application program further comprising defining a first service object request broker, capable of execution on substantially any one of said second plurality of computers, connectable to and in communication with said first service object for relaying communications to and from said first service object.

41. The method of claim 40 of executing an application program further comprising defining a means for asynchronously passing a message from one of said second or third service objects to said first service object by sending a message to said first service object request broker, storing said message, then forwarding said message to said first service object.

42. A method of using a computer to execute an application program on at least two interconnected computers, selected from at least two classes of computers, said method comprising selecting a first class of computers comprising a first plurality of computers, each of distinct types, selecting a second class of computers comprising a second plurality of computers, each of distinct types, any one of said second plurality of computers interconnectable with any one of said first plurality of computers, and selecting a first service object, selecting a second service object, and selecting a third service object, where each of said first, second and third service objects can communicate with at least one of the other said service objects, said first service object capable of execution on substantially any one of said first plurality of computers, said second service object capable of execution on substantially any one of said second plurality of computers, said third service object capable of execution on substantially any one of said first plurality of computers and also capable of execution on substantially any one of said second plurality of computers, providing a heterogeneous environment comprising a first computer selected from said first class of computers and a second computer selected from said second class of computers, said second computer interconnected with said first computer, said second computer of a different type than said first computer, selecting said heterogeneous environment, loading said first service object on said first computer, loading said second service object on said second computer, and selectively loading said third service object on one of either said first computer or said second computer, then executing each of said first, second and third service objects to execute said application program.

43. The method of claim 42 of executing an application program further comprising moving said third service object from said first computer to said second computer.

44. The method of claim 42 of executing an application program further comprising replicating said third service object on said second computer.

45. The method of claim 42 of executing an application program further comprising loading said third service object on said first computer.

46. The method of claim 42 of executing an application program wherein said first class of computers comprises one or more computers selected from the group consisting of a workstation, a personal computer, a laptop computer, a palmtop computer and a personal digital assistant.

47. The method of claim 42 of executing an application program wherein said second class of computers comprises one or more computers selected from the group consisting of a mainframe, a minicomputer, a superminicomputer, a workstation and a personal computer.

48. The method of claim 42 of executing an application program wherein said first computer is a client and said second computer is a server.

49. The method of claim 42 of executing an application program further comprising defining a first means for message transfer for passing a message to transfer information between said first service object and said second service object.

50. The method of claim 49 of executing an application program further comprising defining a first service object request broker, capable of execution on substantially any one of said second plurality of computers, connectable to and in communication with said first service object far relaying communications to and from said first service object.

51. The method of claim 50 of executing an application program further comprising defining a means for asynchronously passing a message from one of said second or third service objects to said first service object by sending a message to said first service object request broker, storing said message, then forwarding said message to said first service object.