Date: Mon, 14 Nov 1994 08:51:44 -0600 To: patterns@cs.uiuc.edu From: johnson@cs.uiuc.edu (Ralph E. Johnson) Subject: the Site pattern At OOPSLA, Bob Atkinson described the Site pattern to me. I realized I knew it, but had a hard time coming up with a good example. The problem that Site solves is that sometimes a server has to keep information about all of its clients. One way it can do this is to keep a table to hold the information and to have each client pass in an ID with each request. It can use that ID to look up the information in the table. The Site pattern is to encapsulate client-specific information in an object that represents the "site" on the server that the client is talking to. The client starts by registering itself with the server, and it is given a site to communicate with. From then on out, it never talks directly with the server, but only with the site. Every operation on the site turns into an operation on the server, however. In fact, most operations are just delegated to the server, passing the site in as a parameter so tht the server can get client-specific information. I can think of some not-so-good examples. One good example from real life occurs when you call a mail-order hours. You get a single person to talk to, who knows about your order, and you only talk to that person. But can some of you suggest some very good software examples? Note that they *don't* have to be distributed. This is a very generic pattern. -Ralph Johnson Date: Mon, 14 Nov 94 10:13:02 -0700 From: Dave McComb To: patterns@cs.uiuc.edu Subject: Re: the Site pattern If I followed that correctly it seems that the general case of problem that this address is whenever you contemplate shipping information over the wire (relatively slow speed) and you want to edit it appropriately for its destination. Possibilities that come to mind are: having the server tranlate text and/or error messages into the native language of the site, translating time of day for the time zone of the site, translating graphics for the capability of the site (not shipping a full color rendering to a black and white site) converting from graphic to non graphic for non graphic sites etc. It can also be used for remote change notification. Date: 14 Nov 94 13:49:20 EST From: Kent Beck <70761.1216@compuserve.com> To: "INTERNET:johnson@cs.uiuc.edu" Cc: Patterns Subject: the Site pattern Cray used to have an on-site technician equipped with microscopic soldering gear and all kinds of cool stuff. How about terminal concentrators? (Not trying to be blasphemous, but...) There have been religions where ordinary people weren't allowed to pray directly to a deity, but instead had to go through a priest. It seems to me that the primary force driving Site is the relative cost of managing local and remote connections. If local connections are easy to manage (because you have a garbage collector, for instance) but remote ones are hard, you can reduce the cost of a system by mostly managing local connections. Remote connections are more expensive to manage because the communications protocols are so much more complicated. You have to worry about time outs, reliability, retries, performance, etc. With local communications you just send a message- if that doesn't work we've got bigger problems. The forces at work are: * The distinction in cost between local and distant communications * Simplicity (narrowly constituted), which suggests a simple many-to-one connection scheme * The desire to reduce connection costs * The need to prove higher-level invariants, which may be possible with Site where it isn't (or is much more difficult) without it Kent Date: Mon, 14 Nov 1994 13:07:07 -0600 From: sane@delirius.cs.uiuc.edu (Aamod Sane) To: johnson@cs.uiuc.edu Subject: Site pattern This sounds very similar to the the general notion of indirection, e.g. file descriptors in unix. I have written a small class library of sockets in which StreamSocket("target") Gives a stream socket. Thus, the program talks only to the stream socket , not to the entire network subsystem. You could say that a small slice of the functionality of the entire networking system is encapsulated in the "Site" (socket object) which then delegates all behavior to the networking subsystem. From: R James Noble Date: Tue, 15 Nov 1994 08:28:48 +1300 To: patterns@cs.uiuc.edu Subject: Re: the Site pattern > But can some of you suggest some very good software examples? Note > that they *don't* have to be distributed. This is a very generic > pattern. OK I'll bite - I think this a very common pattern, especially so where object oriented interfaces are layered over existing libraries. For example, several OO bindings to Xlib reify X resources (windows, fonts, graphics contexts) as language objects. Messages sent to these objects are packed up with the resource ID and relayed to the X server. Perhaps more commonly, the "operating system" can be viewed as a monolithic server underlying the language, and file access also follows this pattern. Unix file ids are represented with File objects; messages sent to the file objects delegate to the Unix object including the appropriate file ID. I'm sure there must be other examples (interfaces to relational databases come to mind) but I'm not really familiar with them: the examples above both come from the Self library. I have one question (although I'm at home and don't have a "The Book" handy to check chapter and verse): how does a Site differ from a Proxy? Presumably a Proxy represents an object elsewhere, while a Site may "objectify" anything. James Noble -- James Noble, Graduate Student, Computer Science Department Victoria University, Box 600, Wellington 1, New Zealand kjx@comp.vuw.ac.nz Date: Mon, 14 Nov 94 11:17:19 PST From: Patrick D Logan To: patterns@cs.uiuc.edu Subject: Re: the Site pattern I can think of one *real* example, you decide if it's good... * I have a server that implements the "factory" pattern. It provides a "factory" per client, since each client can have different sets of objects with overlapping identifiers. ================================================================================ Patrick_D_Logan@ccm.jf.intel.com Intel ProShare Teleconferencing (503) 696-9309 FAX: (503) 696-4210 "What I envision may be impossible, but it isn't impractical." -Wendell Berry Date: Mon, 14 Nov 94 14:57:31 EST From: puder@summa4.mv.com (Karl Puder) Message-Id: <9411141957.AA05036@summa4.mv.COM> To: patterns@cs.uiuc.edu Subject: Re: the Site pattern It looks like you're talking about the Registration/Id-Number pattern. > The problem that Site solves is that sometimes a server has to keep > information about all of its clients. One way it can do this is to > keep a table to hold the information and to have each client pass in > an ID with each request. It can use that ID to look up the information > in the table. > > The Site pattern is to encapsulate client-specific information in an > object that represents the "site" on the server that the client is > talking to. The client starts by registering itself with the server, > and it is given a site to communicate with. Another real-world example is a credit-card company. A person registers with the card-company, giving a lot of supposedly relevant information, which the company stores away. The company gives the person a plastic card with a number on it to serve as an I.D. number. The person can now communicate transactions with many different servers, presenting little more than the I.D. number, and these servers can rely on the card-company (the "main" server) to have the relevant information when needed. If this really is an example if the Site pattern as you know it, please elaborate on how the parts of my example match the Site pattern, and which parts of my example are extraneous. e.e., Is the I.D. number a crucial part of the pattern, or just a commonly associated feature? :Karl Puder. Date: Mon, 14 Nov 94 15:32:11 PST From: Patrick D Logan Message-Id: <941114153211_1@ccm.jf.intel.com> To: patterns@cs.uiuc.edu Subject: Re: the Site pattern >I have one question (although I'm at home and don't have a "The Book" >handy to check chapter and verse): how does a Site differ from a >Proxy? Presumably a Proxy represents an object elsewhere, while a Site >may "objectify" anything. Some possible differences: * Proxies probably behave the same, no matter which client is using them * Sites behave differently, i.e. each client has its own site that effects the behavior of the server. * [Without GoF at my side] Proxy implies "remoteness" * Site, as suggested by Ralph Johnson, does not necessarily imply remoteness. My example of a server using a separate factory for each client is an example of these points, where the factory is the site. ================================================================================ Patrick_D_Logan@ccm.jf.intel.com Intel ProShare Teleconferencing (503) 696-9309 FAX: (503) 696-4210 "What I envision may be impossible, but it isn't impractical." -Wendell Berry Date: Mon, 14 Nov 94 16:43:04 PST From: Patrick D Logan Message-Id: <941114164304_2@ccm.jf.intel.com> To: patterns@cs.uiuc.edu Subject: Re: the Site pattern A couple of other more general, "system level", examples of Site, I think: * Dynamically Linked Libraries in MS Windows allow "per client" data. * Win95 and Windows NT allow "per thread" data allocation, i.e. heap allocation that is available only to the allocating thread. ================================================================================ Patrick_D_Logan@ccm.jf.intel.com Intel ProShare Teleconferencing (503) 696-9309 FAX: (503) 696-4210 "What I envision may be impossible, but it isn't impractical." -Wendell Berry From: lennart@utilia.se (Lennart Ohlsson) To: patterns@cs.uiuc.edu Subject: Re: the Site pattern Date: Tue, 15 Nov 94 09:30:09 GMT+2 Organization: Utilia Consult Reply-To: lennart@utilia.se There seems to be two patterns at work here: one from the server's side and one from the client's side. If the server has to keep information about all of its clients, it means that it may behave differently to the same request depending on who is making it. More generally, its services are dependent on the dynamic context. The normal way to provide dynamic context is to pass it as a parameter but sometimes that is not a good solution. One reason can be that the context is too large and the communications channel is too expensive. Antother reason can be that the context has a complex internal structure which should be encapsulated from the client for information hiding reasons. Possible names that come to my mind for this pattern is Context or Dynamic Context, but I suspect that some more specialized term can be found. I thus see it as not being the site object but a context object which encapsulates client-specific information. If the client passes an ID with each request, the Context pattern is in place but not the Site pattern. The Site pattern encapsulates the passing of the ID so that the client can have its requests executed in its own context without having to explicitly pass the ID each time. If both the Context pattern and the Site pattern are used, the intermediate ID can be avoided. The context and the site can be different roles played by the same object. The client see it as a site and the server see it as a context. - Lennart Ohlsson - Utilia Consult - Sweden Date: Tue, 15 Nov 1994 08:32:49 -0600 To: patterns@cs.uiuc.edu From: johnson@cs.uiuc.edu (Ralph E. Johnson) Subject: Re: the Site pattern I'm impressed by the response! Turning sockets or file descriptors into objects is certainly an example, though I'm not sure it is a good example. It illustrates the alternatives, however. One alternative is to have an ID that you pass into the object you are using, and the object uses that ID as an index into a table to store the information it keeps about you. The other alternative, which is the Site pattern, is to make an intermediate object that stores the information. A File object in Unix looks like the Site pattern to the user (which, perhaps, is all that is important) but is actually implemented with IDs. I consider Site and ID to be competing patterns, not variations of a single pattern. They can obviously be combined, and perhaps there isn't as much difference between them as I am claiming. I think of the ID pattern as being closely related to the Memento pattern in the Design Patterns book. Several people said that they thought that the purpose of the pattern was to improve performance in a distributed system. To me, the purpose is ONLY to simplify a system's design. Instead of having to keep track of both a server and an ID, a client only has to keep track of a single reference. Instead of having to manage a table, the server just has to be able to create sites. I think the real benefits of this pattern occur when you eliminate the IDs, not when you just cover them up. I suppose the Site pattern could be used to improve performance, but I've never seen it used that way. >Possibilities that come to mind are: having the >server tranlate text and/or error messages into the native language of >the site, translating time of day for the time zone of the site, >translating graphics for the capability of the site (not shipping >a full color rendering to a black and white site) converting from >graphic to non graphic for non graphic sites etc. These are all reasons for the server to know the client, but they could be implemented by the ID pattern just as easily as by the Site pattern. Note that "site" is being used here to refer to the server's view of the client, but I was using it as the client's view of the server. The server creates a site that the client can use thereafter. I hadn't thought about the server using the site, too, but it is obvious that it can be done. It is an interesting idea. >Cray used to have an on-site technician equipped with microscopic >soldering gear and all kinds of cool stuff. >There have been religions where ordinary people weren't allowed to >pray directly to a deity, but instead had to go through a priest. An important part of the pattern is that the client first registers with the server to get a site, and then communicates with the site thereafter. Cray fits this pattern, because you call Cray to negotiate a service contract, and then you get your very own repairman. The other example is not so good, because in those situations, people did not go to the diety to get their own priest. Site differs from Proxy because a proxy has the same interface as the object it is proxying, while a Site has a different interface than the server that it belongs to. A File object might be more like a proxy than a Site, though, if you are thinking that the o.s. has these file objects running around inside it and that the File object is just a proxy for one of those files. The patterns have different "intents": a proxy represents another object, while a site is an object that holds client-specific information for a server. You could easily combine these patterns in a distributed system by giving the client a proxy to the site, which is stored on the same host as the server. Note that Proxy can be used in non-distributed system, since it could be used to represent an object on the disk, or an object that hasn't been created yet (lazy initialization of objects). I go back and forth between thinking that these are all slightly different patterns, and thinking that (as in the book) they are all variations of one pattern. I liked Patrick Logan's example. He has a universal factory that can create ANYTHING, and when you register with it, you tell it what you want and it produces a specialized factory that produces just the things you want. The specialized factory is a site on the universal factory, it just keeps track of what you want to build. At least, that is the way I understood it. -Ralph Date: 15 Nov 94 17:03:38 EST From: Ward Cunningham <72147.3056@compuserve.com> To: "INTERNET:johnson@cs.uiuc.edu" Cc: Patterns Subject: the Site pattern "The problem that Site solves is that sometimes a server has to keep information about all of its clients." -- Ralph Johnson So, I gather, the use of Sites eliminates the need for the server to keep per-client information. Many followups to Ralph's posting seem to confuse Site objects with IDs. An ID certanly does not relieve the server of per-client record keeping. I took Ralph's discussion of ID as an example of the problem to be solved, not the solution. If the server has an unbounded number of clients then the server-side record keeping to support IDs is also unbounded. The Site pattern offers the alternative of passing all per-client information back to the client in place of an ID. Then a bounded server can support an unbounded number of clients. Two forces are present in this pattern. First is an unbounded (or just large) number of clients. Second, and opposite, is the need for security in the per-client information. The number of clients may be unbounded simply because there is no way to safely revoke the client-server relationship. Presumably objects provide some level of security to the information within a Site object. The client need-not know that it is not simply an ID. A bank keeps information for each bank card it issues. This makes bank cards a poor example of the Site pattern. A better example would be BART (Bay Area Rapid Transit) cards. These cards carry unused fare from which deductions are made with each trip without consulting any other database. From the above forces we see that a BART card need never expire, but, may be subject to novel abuse. In fact, a nearly consumed card can be "refreshed" from a full card by placing the two cards together under a hot iron until the first card's magnetic strip reaches the Curie temperature. The Site pattern appears in my implementation of FileStream in Tektronix Smalltalk. These objects duplicated the information in an "open file descriptor" so that the number of files in use at any time could be unbounded. A side effect was that the use of open and close became purely optional. Should you write on a closed file, it would be reopened and positioned appropriatly. The fact that files were sometimes left open between FileStream operations was simply a performance optimization. Many thanks to Bob and Ralph for recalling this neat pattern. -- Ward Cunningham Date: 15 Nov 94 12:26:00 EST From: Kent Beck <70761.1216@compuserve.com> To: "INTERNET:lennart@utilia.se" Cc: Patterns Subject: Re: the Site pattern The other force I didn't realize is the desire to keep the client-side objects unaware of the remoteness of the server. The Site tacks a "client-id" onto messages it forwards to the server, freeing the client objects from having to know that any such concept even exists. Kent To: patterns@cs.uiuc.edu Subject: Re: the Site pattern Reply-To: Don Dwiggins Date: Tue, 15 Nov 94 10:21:41 PST From: dwig@markv.com Sender: dwig@markv.com Site isn't necessarily restricted to client-server. If we have a pattern called Session or Dialogue, with the obvious intent, then Site is a means for an agent that is participating in multiple sessions, to keep track of the context for each. (An important feature of a session is that it's a connected sequence of interactions, in which each interaction may use ambiguous or abbreviated references to things; the context provides the information needed to find the referents.) Don Dwiggins "Solvitur Ambulando" Mark V Systems, Inc. dwig@markv.com Date: Tue, 15 Nov 1994 14:29:07 -0600 To: patterns@cs.uiuc.edu From: johnson@cs.uiuc.edu (Ralph E. Johnson) Subject: Re: the Site pattern I sent my last message before receiving Lennart Ohlsson's. That is a feature of reading mail on a disconnected network. I liked his analysis very much. (But he didn't give an example, either!) So, there are two patterns here, Context and Site. Note that an opaque Context is a Memento. Does that mean Memento too specialized, and we should replace it in the Design Pattern book with Context? Most of the examples that have been given are Site without Context, while I was looking for examples where Site was used with Context. Does anybody have examples of that? I understand now why a couple of people thought that the purpose of Site was to reduce communications cost. I think of it as reducing the number of objects that the client has to deal with. Since I think that no method should deal with more than four or five interesting objects, this last reason is important to me. -Ralph Date: Tue, 15 Nov 94 14:04:06 -0700 From: James Long Message-Id: <9411152104.AA18952@bswat.com> To: patterns@cs.uiuc.edu Subject: Re: the Site pattern > From patterns-m@a.cs.uiuc.edu Tue Nov 15 13:23:45 1994 > X-Sender: johnson@128.174.252.11 > Date: Tue, 15 Nov 1994 08:32:49 -0600 > To: patterns@cs.uiuc.edu > From: johnson@cs.uiuc.edu (Ralph E. Johnson) > Subject: Re: the Site pattern > . > . > . > . > Site differs from Proxy because a proxy has the same interface as the > object it is proxying, while a Site has a different interface than the > server that it belongs to. A File object might be more like a proxy > than a Site, though, if you are thinking that the o.s. has these > file objects running around inside it and that the File object is > just a proxy for one of those files. The patterns have different > "intents": a proxy represents another object, while a site is an > object that holds client-specific information for a server. You > could easily combine these patterns in a distributed system by giving > the client a proxy to the site, which is stored on the same host as > the server. Taligent's Guide to Designing Programs" has an interesting discussion of "Surrogate" patterns - pg. 91-96. The Site pattern is similar to what they refer to as "A surrogate that views a master". In this pattern the surrogate is a proxy for an explicit master object, "but the surrogate isn't a direct stand-in for the master object. Instead, it is a synthetic or virtual perspective on that object". Date: Tue, 15 Nov 94 16:49:09 PST From: Patrick D Logan Message-Id: <941115164909_3@ccm.jf.intel.com> To: patterns@cs.uiuc.edu Subject: Re: the Site pattern Text item: >If this is a pattern, what problem does it solve? In particular, what >are the forces that shape how I think about this problem and the alternative >solutions? Here's a proposed problem statement: An object has been identified to provide a service for more than one other object. The service provided in each client/server pair will be affected by the particular client. Moreover, the server will need to retain some information about each client; information that the client may be not wholly aware of itself, but becomes known to the server as a result of its connection to a client. ================================================================================ Patrick_D_Logan@ccm.jf.intel.com Intel ProShare Teleconferencing (503) 696-9309 FAX: (503) 696-4210 "What I envision may be impossible, but it isn't impractical." -Wendell Berry From: lennart@utilia.se (Lennart Ohlsson) To: patterns@cs.uiuc.edu Subject: Re: the Site pattern Date: Wed, 16 Nov 94 09:21:04 GMT+2 Organization: Utilia Consult Reply-To: lennart@utilia.se An example of Site and Context used together is in the Choices' file system framework [Madany 92]. The class FileSystemInterface is the access point (site) to the file system (server) for application programs (clients). The FileSystem- Interface does several things, but in particular it keeps track of the current directory (context) of the client. Choices also uses streams as client interface objects to files. Are they also examples of the Site pattern? They do encapsulate a "server" (the file) with the context (the current position). But streams don't feel like sites. They are more closely related to external iterators. Ralph's purpose statement seems fit to make the distinciton: streams don't reduce the number of objects that the client has to deal with. Maybe there is a more general pattern lurking here, of which stream and site are specialisations. Any suggestions? [Madany 92] P. Madany, "An Object-Oriented Framework for File Systems", PhD thesis, Univeristy of Illinois UC, 1992. - Lennart Ohlsson - Utilia Consult - Sweden From: Richard Helm Subject: Re: the Site pattern To: johnson@cs.uiuc.edu Date: Wed, 16 Nov 94 8:47:12 EST Cc: patterns@cs.uiuc.edu We use this pattern alot ( Although I wonder if we all really see this pattern the same way - I am reminded of blind men and elephants - examples are crucial) Pattern: Invisible Managers Intent: Isolate clients from operations objects that require a global context, by exposing these objects in only a local context. Motivation: We have objects managed by a server, and clients who wish to deal with these managed objects. Moreover, * there are constraints over the managed objects which the server must maintain, which are global accross managed objects, or * operations on the ManagedObject require more global knowledge which the client and ManagedObject does not or cannot know about and you wish to isolate clients from having to worry about this global information. Hence you expose the managed objects to the clients in such a way that clients see individual managed objects, but any request the client makes on a managed object gets forwarded to the Server so that it can enforce any necessary global constraints or employ global information across the managed objects. Clients therefore get to see ManagedObjects in a LOCAL context, but operations are perfrormed on ManagedObjects in a GLOBAL context. Particpants: There are 3 particpants. Server - provides clients access to managed objects - enforces constraints over managed objects ManagedObject (Site? hate the name, implies a locale) - use by client - forwards request made on it on to Server with self as argument (hence it looks a little like a Proxy) - implements two interfaces, one used by client, and one used by Server to to the real work (hence it looks a little like a Memento) Client - requests ManagedObects from Sever - thereafter makes all requests on ManagedObject Some Examples: In the constraint solving framework that John V. and I worked on at IBM the ConstraintSolver was the Server of Variables, clients only dealt with Variables. Operations performed on Variables, (assignment in particular) were forwared to the solver (with the variable and the new value as arguments) to re-solve the constraints. Clients were not aware the solver even exisited. Other examples appeared in earlier postings > So, there are two patterns here, Context and Site. Note that an opaque > Context is a Memento. Does that mean Memento too specialized, and we > should replace it in the Design Pattern book with Context? Where would Volume II be if there werent more patterns. Memento has a different intent. It is about restoring state! -- Richard Helm: Richard.Helm@dmr.ca DMR Group, 1200 McGill College Ave., Montreal, QC, H3B 4G7, Canada Client: Phone: 514-738-8300 ext. 2195. Fax: 514-345-7982 DMR: Phone: 514-877-3301. Fax: 514-877-3351