Tuesday, September 8, 2009

BA Ch 4 & ArchJava

Both the BA Ch4 and the ArchJava paper relate to a quite elusive concept (at least to me) in the modern world of software, which perhaps is just an embodiment of software architecture in general, but whose specific instances really hit home for me: How do you take a set of (potentially) idiomatically distinct libraries, frameworks, and ideologies, and merge them with the ideal view of how software should fit together?

Disclaimer: I can't speak from a Java perspective, as I somehow managed to get my whole BS in CS without writing a single line of Java, so I'm going to have to use .NET technologies as a close substitute.

ArchJava approaches this question from the standpoint of language enhancements on top of Java, where they ask for any code you write to be reworked within a paradigm of a component hierarchy, ports, and connections.  One big problem I have with this, and with many idealistic patterns and practices, is that they often times fail to recognize and leverage the existing infrastructure that constituent software brings to the table.  For example, using something like ArchJava, writing an ASP.NET page, which already has its own concept of component (or control) hierarchies and communications strategies, I'm not quite sure where we're left with an ArchJava type solution.  You might say that we'll consider the whole ASP.NET subsystem to be excluded from the ArchJava-type code model, but then as soon as you try to perform extension in a few different ways (such as control subclassing or HTTP pipeline processing addins), you break that scope, and it seems that only the much less strict, and less powerful mode of ArchJava can be used.

The chapter "Architecting for Scale" grapples with this question, though it doesn't provide extensive detail on a proposed ideal solution to the extent that ArchJava does.  I found the Form/Binding paradigm to be very interesting, in that it goes a long way to leverage existing technologies (such as SWING), but generates a wrapper/abstraction that allows the developers to work within the application's paradigm. The buy vs. build decisions also play into my question, as the "roll your own" is guaranteed to be much closer to the ideal architectural style, though potentially less robust, and often more expensive.

One thing that, being from the .NET world, I see as paramount, is the design time support for these tools and paradigms.  In ArchJava, for instance, the proposed solution supplants the standard compiler for an  enhanced version.  This is all well and good, and can easily integrate with a build flow, but at design time, the developer is left with constructs which, while they may compile with the extended compiler, are not (necessarily) intrinsically supported by things like code coloring, refactoring tools, intellisense, and perhaps code analysis tools.  In my opinion, these shortcomings make this type of tool more bleeding-edge and disruptive--perhaps to a greater degree than the benefit they provide.

No comments:

Post a Comment