Component Design Patterns Discussion

Let this be the place where people can offer feedback, comments, or discuss the general state of progress (or lack thereof) in the project as a whole.

Here are some legacy pages we created before that aren't part of the core interface for the language, but have some good content/thoughts to look at if you're bored:

• ComponentDesignPatternsStrawman
• ComponentDesignPatternsIntroduction

One dimension we are seeing is that of space. Space is important in CBD because components can exist in a system and relate to each other in the domestic space (e.g., in the same address space), and/or in the foreign space (e.g., in other address spaces that might be physically distributed over a network of machines). Some patterns focus on domestic space and are extended by patterns solving problems in the context of foreign space.

-- PhilipEskelin

People can confuse this with software process...perhaps it should be changed to DefineSpatialBoundaries? or GiveComponentsTheirSpace?. -- PhilipEskelin

How about AddressSpaceBoundary?? It is easier to work a pattern's name into a sentence in a natural way if it is a noun phrase. -- NatPryce

My only worry is that some environments including Java don't have the concept of an address space. That's why I came up with the concept of foreign and domestic space. This is abstract enough to apply to all CBD environments I know of. So the question is, what would you call the process of making decisions about the special location of different bought or built components in your application? -- PhilipEskelin

I'm not sure about Java not having the concept of an address space. Isn't the JVM the address space? And what about JavaSpaces (though one could argue they are more about name services and registry, but they're also about some type of distributed persistent space as well - like having a booth at a tradeshow ;-) -- BradAppleton

Address space is usually an operating-system rather than a language issue and so languages, including Java but also lower level languages such as C and C++, assume a single address space and don't address the issue directly (no pun intended). Instead libraries are used that take advantage of OS facilities to communicate between address spaces. I suppose that the virtual machine is the Java equivalent of a process or address space. RMI is described as allowing objects in different virtual machines to communicate, and so I guess that assumes that a single JVM is a single address space.

ANSA calls address spaces "capsules" but I find that ugly :-)

Should SoftwareProcessThatFits? be higher-level? One thing to note is that component assembly is somewhat different from component development. Decisions made in the architecture patterns like CautiousBuyOverBuild affect whether you build solely from components. Does CookbookApproach belong in ComponentDesignPatterns? The original idea was if you build instead of buy, a cookbook approach to component creation can help produce consistency and quality. -- PhilipEskelin

Phil, Kyle, and Nat:

All I can say is "Wow!" This is turning into something fantastic!!! Im glad you took the initiative to use the Wiki for this project Phil. In about 6 more months I think you all may just have the better part of a book. I would be very interested in seeing you guys manage to "work in" some of Nick Jacob's patterns from PLOP98 (Garden of Applications) since I think many, if not all of them are quite applicable here.

My only criticism is: Where are the forces?

You document a context, problem, solution, resulting context, and known uses for all your patterns. But the forces seem to have been ommitted. I know Im not alone in my feeling that forces are among the most important aspect of a pattern. They are the biggest pain to grapple with, but doing so pays dividends in the amount of insight conveyed about how and why the pattern is desirable.

So, definitely keeep up the good work, guys! But, to paraphrase Cuba Gooding Jr. in the film Jerry Maguire: Show me the forces! :-)

-- BradAppleton

Brad, thanks very much for commenting on our work. I hope you already know that I have the highest respect for you, based on our mutual participation in the PLoP 98's Network of Communication workshop. I am delighted that you are excited about our progress, and take your feedback seriously. Truthfully, over the last few weeks, it's been a bit quiet, but these things happen in this business :-)

AbsenceOfForces a problem? --agreed. Perfect!!! My feeling since day one is that we would piece together incomplete strawmans of ideas (ProtoPatterns as some call them) and go from there. Chaos is our friend -- we've never really discussed format or content or where this thing should go . . . and I like it that way!

While a book could happen if we're at right time/right place, it isn't being emphasized. (If it was, you'd see stacks of business cards and snake oil carts packed full with our book at the next PLoP <multiple nefarious grins>.) Whether the RuleOfThree or AbsenceOfForces or any other force causes our demise, no money will be lost. And we only have forces to gain. I'll do my best to consider this feedback in my next iteration, but if you have any specific comments or ideas, feel free to add them!

-- PhilipEskelin

I've started adding a Forces sections to the patterns. Feel free to add, modify or clarify the forces as you see fit.

I'd also like to see the patterns become more interlinked. For example, the Resulting Context sections can introduce new problems and link to the patterns that solve them. Not all patterns have a Resulting Context section. The GOF format has a Related Patterns section but this is not quite the same, although it often includes information about the resulting context. What do people think... is the GOF format quite right for this kind of pattern language, which ranges from high level architectural and process oriented patterns to low level design patterns?

--NatPryce

A very good question... I think that this should eventually be described on the ComponentDesignPatterns index page.

The definition of a component I use is a piece of software to be plugged into a framework. This is a bit of a vague definition I guess, but covers pretty much everything that people call components. I don't think components can exist without a framework. E.g: ActiveX components can only be used within the COM framework, JavaBeans in the JavaBeans framework, Regent protocol components within the Regent transport framework and so on.

But that introduces the question "what is a framework?" which is another can of worms entirely!

--NatPryce.

I moved our subsequent discussion on component frameworks to the ComponentFramework page. --PhilipEskelin

Nat, my thinking is that we would place these in ComponentDesignPatternsContext in order to set the context for the entire language appropriately. You're right, the word framework and the definition of component itself could start a holy war. --PhilipEskelin

NatPryce: The discussions on ComponentDesignPatternsContext have resulted in a very good set of features that distinguishes ComponentBasedDevelopment from object orientation. And there hasn't been a holy war :-).

The results of that discussion made me think about how one goes about ComponentBasedDevelopment. Here's a first stab at the steps one takes:

1. Select components and frameworks that address some/all of the problems you need to solve.

• CautiousBuyOverBuild, LayeredFrameworks, DistributionOfComponents

• CautiousBuyOverBuild, CookbookApproach

• DistributionOfComponents, ProcessBoundary, TransparentDistribution, GoingThroughCustoms, FacadesAsDistributedComponents

• CookbookApproach, ComponentGlue, InterfaceDiscovery, StructureOfSpecialization (?)

• StructureOfSpecialization (?), ComponentGlue

• ContextIndependence, ContainerIndependence, AbstractInteractions, ThirdPartyBinding, ComponentBus, ComponentGlue, SplitDesignTimeAndRunTime, LayeredFrameworks, PrebuiltFunctionality, ComponentAssembler

PhilipEskelin: I moved our framework discussion to ComponentFramework. Otherwise, my thoughts are that you're attempting to define some of the elements -- at the higher levels of the pattern language -- that you can use in a particular context to solve a problem to make a system whole. Part of this has been done, but a lot of what you point out hasn't been explicitly addressed enough (it's scattered throughout).

NatPryce: I've placed some pattern names in the list above where I think they fit. One thing that this made me realise is that thinking about distribution issues is fundamental, but also orthogonal to designing the support for componentisation. Therefore, it could be organised as a separate branch of the pattern language with cross-links to other branches.

PhilipEskelin: Uh, yep, maybe, but I'm not sure. It all depends on how we approach the language -- or what kinds of patterns the user of the language would start with when sitting at the context of the entire language itself. When they've utilized the language, they are in the resulting context of the language. In there, a lot can happen. I think you are onto something here.

In addition, StuartBarker proposed (through e-mail) component assembly patterns, component development patterns, component framework patterns, and a sort of "decision making" subsection. This is also an interesting taxonomy. In end, we can see that classifying them at a lower level into creational, structural, and behavioral might be unnatural.

More natural is that you are sitting in an instance of a context that has lots of overlap with the language's context, and you need to easily identify with where you're at and have an unambiguous path into the guts of the language. It's almost as if you assess what you have and what you need to build for both components and frameworks, and then you compose the entire system both from (primarily) assembly and development roles. Hence assembly and development can be major sub-languages that you utilize appropriately based on your role and context.

One thing you don't address a lot above is component development. This is where my head sits. I think this is why I started more along the lines of CommandPatterns, ConnectionPatterns, and DataPatterns?. I'll try to flesh that out a bit more and add it to your strawman above. -Philip

NatPryce: I think we need MultipleCrossSections to allow different paths into the pattern language.

PhilipEskelin: Yep, nothing wrong with more than one taxonomy or entry point. Somewhere in patterns discussion this was discussed (by I think both Brad and/or Cope) -- that a pattern language can contain other sub-pattern languages, but that it doesn't imply there's only one entry point or that pure object-oriented principles apply to its structure. One taxonomy could be from the role perspective, another from the spacial perspective (foreign vs. domestic space), and another from the perspective of interaction. Any thoughts or modification to these examples? -Philip

PhilipEskelin: I modified definition #1 up above to include components and LayeredFrameworks. Perhaps we should try to ThingsInThrees (but we shouldn't let this limit ourselves, since pattern languages aren't necessarily hierarchical (read NikosSalingaros' work on pattern languages and structure)).

PhilipEskelin: How about Jini and its complement to Java and the Java virtual machine? All devices plugged into the network are physical components with interfaces, and the services of Jini have interefaces themselves. InterfaceDiscovery happens both ways when a new device plugs into the network (e.g., the ComponentBus in our case). Joining and lookup are also intriguing. Do we have patterns in these areas that have been prototyped for ComponentDesignPatterns? If not, should we?

DavidAllsopp: There's a whole range of related technologies that require lookup, including most agent-based systems and some web service-based systems. Incidentally, Jini is often used for software services, as well the physical services (printers etc) originally envisaged.

Some other things you might want to cover:

Factory connections:

The Factory pattern is particularly relevant here. With CORBA, the server returns an object reference to the client. The component lives on the server. The client establishes a connection with a factory that lives on the server (i.e. the CORBA Naming Service is an example), then invokes on the factory to get an object reference for a component that the client wants to use. The component on the server might be shared by multiple clients.

In that case, the factory (or something else on the server side, i.e. the CORBA ORB) needs to maintain an ObjectReferenceCount? for each component that it hands out object references for to clients. When the ObjectReferenceCount? is decremented to 0 (i.e. no clients currently hold object references for that component), the component is freed on the server side.

It is also possible to have a factory which can lock a specific component for exclusive access by a specific client, as part of looking up the component and returning the object reference of that component to the client. In this case, it becomes more important to maintain the ObjectReferenceCount? on the server, since otherwise the client could crash while the component is locked, thus not allowing the server to release the lock on the component and make it available to other clients.

This type of component cleanup may fit in the scope of the ConnectionObserver pattern. You could look at the CORBA Life Cycle service for ideas here. One method I like is to have the client pass a callback object reference into the server factory method; the server associates this with the component, and later uses this callback to "ping" the client, when necessary, to see if the connection to the client is still valid. If the client doesn't respond to the callback, then the server can decrement the ObjectReferenceCount? of all components that the client had been given object references for.

Another method is to implement a connection timeout, or a inactivity timeout on individual components - i.e., if a specific component on the server has not been invoked on for a specific inactivity timeout period by any client, then the lock (if there is any) on the component is removed, either the component is then made available to be accessed by other clients or it is freed.

Remote vs. Local iteration:

For performance reasons, it is often undesirable for a client to remotely iterate over a whole collection (i.e. a sequence) of components when that collection resides on the server - better to have the server serialize the components, and ship the entire collection (or a chunk of it) over to the client so that the client can locally iterate over it. The Proxy design pattern might be useful here to hide the additional complexity added by serialization and keep the interface provided to the client code the same?

Session management/security:

Specifically, how can a component on the server side know what principal is invoking on it, so it can implement some type of ACL-based security to verify that the principal has the required rights. You could look at the CORBA Security service for ideas here. One method I like is to have a Login method return an opaque Credentials object reference to the client, then the client passes this into the server factory method. The server factory can then associate the client Credentials with the object reference that it returns to the client, making the client Credentials available to the component so that when the client invokes on the component, the component can use the Credentials to check to see if the client is authorized.

Ed, just wanted to let you know that I have read your comments multiple times and that we will be taking these assertions/recommendations into consideration from this point forward in the evolution of this language. One thing we haven't touched upon a lot yet is security in distributed systems. Thanks for taking the time. -PhilipEskelin

I added a page on SourceForScience that raises the issue of access to component source and asks how it might impact the development of ComponentDesignPatterns.

--ScottJohnston

Discussion continues at ComponentDesignPatternsDiscussionTwo

--PhilipEskelin

This page mirrored in ComponentDesignPatterns as of April 29, 2006