5.1 Components


5.1 Components

The standard synchronous drawbridge technologies are all based on component technology. Component technology is somewhat based on object-oriented technology. Let me start, then, by giving the briefest of introductions to object-oriented technology as it applies to component technology.

An object is a little blob of software functionality that can do something for you if you know how to ask. A request to an object to do something is referred to as a method invocation . Theoretically, an object has an interface. That interface defines what, exactly, you can ask the object to do, how you must ask, and what, if anything, the object will return in response. In reality, most object-oriented languages support but do not require interface definitions for objects. For the purpose of this discussion, I will assume that all objects are defined by interfaces.

Figure 5.1 shows the relationship between the client (you) and the object instance.

Figure 5.1. Client “Object Relationship

A given interface definition can have many implementations . A specific interface implementation is called a class . You can actually write code knowing only what interface you're using and having no idea what implementation class you're using. You can do this because the object-oriented system chooses an appropriate class (implementation) at runtime to serve as the recipient of the method invocation.

The ability to define one interface, implement it many times, and then have the system choose the most appropriate of those implementations on the basis of clever heuristics goes by the term polymorphic method resolution . Polymorphic method resolution is the basis for framework architectures and is therefore an important feature of object-oriented programming languages.

Components are a lot like classes; each component is an implementation of an interface. The interface implemented by a component is called a component interface . Like their object-oriented counterparts, component systems typically support polymorphic method resolution. The blob of software on which you can make requests , analogous to an object, is a component instance . The requests are described as method invocations .

So what's the difference between objects and components? They sure look alike. There is really only one major technical difference. Objects always reside within the process from which they are called. Components do not. You can probably sense why I'm so interested in components. One process is making requests of another process. It sounds a lot like the makings of a drawbridge, doesn't it? But I'm getting a little ahead of myself .

How do you communicate to a component in a far-off process? Either you need to have a lot of knowledge about communicating over distributed protocols (not likely), or you need to have something in your process that communicates on your behalf . That something is called a component surrogate because it is a local surrogate for a component that is really someplace else, in a different process. Some people prefer the term proxy to surrogate .

The far-off process in which the component instance really lives is called the component process . The component process also needs help with communication. Its helper is called a client surrogate because it is a surrogate for something (you) that is actually in another process (your process, the client process).

Figure 5.2 shows the relationship connecting the client (you), the two surrogates, the component interface, and the component instance. Technically this relationship is known as remote method invocation (RMI). If you have used remote procedure calls (RPCs), this will all look familiar. You might think of components as remote procedures plus polymorphic method resolution.

Figure 5.2. Client “Component Communications

The client of a component can be almost anything, including another component instance. If the client were another component instance, we could naively implement a drawbridge directly as a remote method invocation. Figure 5.3 illustrates such an implementation.

Figure 5.3. RMI Implementation of a Drawbridge

There are two things wrong with this naive implementation of a drawbridge as a remote method. The first is that we are missing the guard function on the recipient side. No guard, no security! The donor fortress may have a high opinion of itself, but the recipient fortress should be more cautious. The second thing wrong is that if the recipient fortress returns any information to the donor fortress (as would be normal in a component method invocation), there is no security in that direction either.

Does all this seem overly paranoid to you? Probably, but paranoia is a good trait when we are dealing with software fortresses . Without any guard function, we have many opportunities for a miscreant, represented here by Bart the bad guy, to stick his nose where it doesn't belong. Figure 5.4 shows some of the ways that Bart might try to take advantage of this unguarded system.

Figure 5.4. Points of Vulnerability in an Unguarded Fortress

Unguarded fortresses may not be as vulnerable as they seem. Some synchronous drawbridge protocols have built-in guard and/or wall functionality. In general, drawbridge protocols that have such built-in functionality fall into the category of homogeneous synchronous drawbridges . Drawbridge protocols that, at least today, have little or no built-in guard and/or wall functionality generally fall into the category of heterogeneous synchronous drawbridges . I will discuss these two drawbridge types in Sections 5.2 and 5.3, respectively.

A fully secure architecture should use a guard for all incoming communications. This is true even when that incoming information is being returned as a result of an outgoing synchronous request. When fortresses are connected through synchronous drawbridges, the guard of the receiving fortress is effectively an envoy of the return information, and the envoy of the donor fortress is also effectively a guard when that result returns.

Here, then, is my preferred architecture for all synchronous drawbridges: The donor fortress uses the envoy half of an envoy/guard to post the infogram to the recipient fortress. The recipient fortress receives the message with the guard part of an envoy/guard. When it is ready to respond, it uses the envoy part of the envoy/guard to do so. The responding infogram is received by the guard part of the envoy/guard in the original donor fortress. This arrangement allows both the original infogram and the responding infogram to be subjected to whatever security inspections are deemed necessary. This configuration, without the surrogates, is shown in Figure 5.5.

Figure 5.5. Preferred Security Configuration for Synchronous Drawbridges



Software Fortresses. Modeling Enterprise Architectures
Software Fortresses: Modeling Enterprise Architectures
ISBN: 0321166086
EAN: 2147483647
Year: 2003
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net