DiegumZone. Who Wanna Be An Architect? : Aspiring Solution Architects

Agility: Automation for Better Outcomes and Feedback

diegumzone — Mon, 04 Dec 2006 08:33:00 GMT

A bad habit of several developers has to do with entering in a long tunnel of coding for an application project, relegating a more or less acceptable executable for the last project stages. That has several risks:

Feedback from users and customers delayed, what can carry a poor customer satisfaction for who was going to receive the outcome. Business are in constant change so late delivery can bring outdated results
Urgent and/or expensive changes for the developing team, and in those environments of changes made under great pressure, conditions for bugs proliferation are optimal :-D
When that happens, when bugs are running everywhere, the vicious circle recycles: more urgent and/or more expensive changes with even better conditions for bugs generation
Those can lead to a dead end known of project paralysis, manifested in the moral of developers, analysts, architects and project leaders, due to the fact that every initiative to regain control is anyway expensive and requires, although the previously invested effort, a new one greater
This project paralysis can affect also the user / customer side, when the confidence on the outcomes is ran out
After this happens it comes… Not. Nothing comes after this: when the confidence runs out, the project is over

So the key here is achieve a schema of frequent builds for iterative, incremental running results. But trying to adopt that practice manually is stressful and could lead to early lack of motivation

So the key of the key has to do with automating the building process. Turning it to a industrial scale. Fortunately several tools can leverage us with building automation (MSBuild, NAnt, NMake), unit testing (NUnit, NUnitForms, Visual Studio 2005 Testing support, etc) and code analysis (FxCop, ...)

In his ninth chapter on the webcast series "Architecting Desktop Applications", PhD. Joe Hummel will show us how static code analysis prevents, in compile-time, design rule breaching (for instance for security, low coupling, performance, naming conventions, etc) thanks to a built-in VS2005 extensible mechanism known as FxCop. This feature is fundamental in those cases where source code is being written by several people with different styles, background and knacks

Also, learn how repeatable unit testing helps you keeping component health under control for those sudden changes with VS2005' Testing projects and its assertion mechanism. This will surely avoid several debugging hours. Here, the code coverage will give us a reliable estimation about how many code is really being subject of tests (with the possibility of finding out which code lines aren't)

Finally, you'll be taught about scaling the process of building, analyzing the code and running the tests through a facility included with the Visual Studio 2005 distribution called MSBuild. MSBuild is the process that VS2005 launches in background every time we select rebuilding our project. Here you'll see how to schedule MSBuild to build our project with a regular frequence. What about nightly builds, for instance? That would be helpful to know, as soon as possible, if a newly integrated source file is making fail some tests

So, what else can I do? Just point where the webcast is:

Build, Build, Build, Test, Test, Test

From Classes To Components

diegumzone — Mon, 13 Nov 2006 08:41:00 GMT

In n-tier, distributed applications, we have to decide which logic deploy where. Those deployments are all about installing components in specific places but, what are components exactly? What distinguishes a component with respect of a mere class?

Actually, as classes do, components take ownership of cohesive responsability but components are logical units from a physical perspective. In MS .NET terms, components are redistributable assemblies (.dll) of one or more classes

But, wait, it's not so easy: new considerations arise in this context

Security: When one part delivers a component to some other, how can the receiver be sure he/she's loading the original component (not tampered, not violated in any way). How can the sender be sure that calls to his/her component come from the receiver and not from someone else who got an illegal copy of the component? How can we protect, given a component, about illegal decompiling, illegal use of reflection on it and, most of all, illegal inheritance from one or more classes which, under the façade of the expected ancestor, expose a different behavior than expected?
Versioning: how to deal with different versions of a component without breaking usage for legacy clients of such component? In the previous infrastructure, Windows DNA, such issue was known as DLL Hell
Configuration: where must be put, in the Setting.settings project file or in the app.config file? What if the solution has several project-components? Where the component config info has to go in such scenario?

In this eighth webcast, Dr. Joe Hummel focuses on the design and creation of .NET components. He explains what component references are and how the .NET CLR deals with them via component metadata

With respect of security issues, Hummel offers some notions on Threat Modeling and how to avoid it via strong-named assemblies

About versioning, know the benefits of the .NET's Global Assembly Cache and how it says bye-bye to the Windows Registry (leaving behind the DLL Hell)

Finally some notions of pluggable components or, said in other words, what role play in .NET the elements configuration, configSections, sectionGroup and section? What role plays the applicationSettings element? Tired of being tired of never finishing to understand it?

So come on, join us again and let's watch together a new chapter of Dr Hummel's series "Architecting Smart Client applications"

Turning Tiers into Components

Software Architecture: Past, Present and Future

diegumzone — Fri, 10 Nov 2006 07:32:00 GMT

What is exactly software architecture? Do we really need it? Why have we only recently been discussing it? Is there suddenly a contagious fever about software architecture infecting those who claim to be architects? Who are they actually: gurus, just senior developers, or maybe smooth-talkers?

These are questions that developers, junior and senior, are asking about software architecture and software architects. In this article we, the members of the MS Architecture Strategy Team, will answer all of them and even more: we will face the forbidden question “Can a developer become software architect?”

The Need for Software Architecture

A longtime ago, programming platforms were more self-sufficient than nowadays. From robust and complex environments like mainframe COBOL to light and easy to understand xBase languages, the most important technical decisions were already taken. In terms of software projects, that implied both benefits and deficits. A benefit, because where a decision exists, no time needs to be spent in discussions about the best way to do anything.

In non enterprise environments (academics, small business), this solutions model was adequate and successful for a long time. But it was a deficit as well, because at the largest companies, there was one notorious downfall - “all-or-nothing” platforms were too rigid to adapt to the competitive, highly changeable environments required by a global economy. Also, during mergers and acquisitions, it’s really hard to get two self-sufficient platforms to play togetether.

Thus, component-oriented software was born with the goal of a new agility in scaling applications. This style of applications enabled us to choose among a broad set of platforms, to produce modular pieces (or components) ready to be used by other components made by us or bought from third parties. Once we could prove that integration was not an issue, this feature gained popularity in the enterprise, where the technical decision makers discovered the advantage of using the right platform and tools as solutions for specific problems. However, eventually the need to plan and manage components became evident to guarantee the success.

Defining Software Architecture

So, thanks to component-oriented software we could choose the platform which best fit a specific problem. Despite that, the paradigm shift of new platforms was difficult to learn for many developers. Thus, one of the first objectives of a good architecture was to gently hide the complexity of new platforms and APIs behind simpler ones, more focused in the context of the problem being solved (typically a business problem), and, most of all, easily understandable by regular programmers.

That way software architecture became a highway to develop business solutions in a timely, secure, accurate manner. Under the pavement of that highway is nothing but technological decisions, the critical ones. Decisions the architect had to take to make the developers’ tasks easier.

The difference with past platforms is that now, rather than buying general purpose software from a vendor, an organization’s members make the decisions regarding the function of the business solution to be developed.

What Software Architecture Used To Be

Software Architecture emerged from a bundle of practices that applied by senior developers. Some of these merit mention:

· Design Patterns. The legend started with a book called simply “Design Patterns” (http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612) that is still a best seller. These patterns cover highly decoupled, reusable solutions for frequent problems about responsibility assignment in object-oriented programming (OOP). Actually, they merely solve the problem at a small scale, but surely this book sowed the seed for a new way of thinking about applications, constituting the DNA of several enterprise systems. We suggest as a reading the article “Last Call to Design Patterns,” at http://www.skyscrapr.net/blogs/solution/archive/2006/07/30/248.aspx

Figure 1. The Strategy Pattern, as explained in MSDN Magazine (July, 2005)

· Architecture Patterns. In the days of Smaltalk, one pattern proposed an extraordinary way of decoupling user experience from persistence mechanisms. This pattern, the Model-View-Controller, granted the responsibility of user interaction handling to a component which played a role known “the View.” “The Model” component had the responsibility of consistently keeping the business model state. A third component, called “the Controller” interpreted events originated from the View, promoting changes in the Model state accordingly. This pattern permitted very inexpensively interchanging components of any role, thus enabling multi-channel applications (that is, applications available in a vast variety of platforms and contexts). Think beyond the typical dichotomy of client versus server. Think of ATMs, mobile phones and other platforms. We have just to re-implement the View component in these use cases (“Bill payment,” “Book service,” and so on). The same applies to the Model. It isn’t just a discussion about Oracle versus SQL Server versus IBM DB/2 versus MySql vesus whichever. Think also of legacy mainframe environments or XML files for smaller data repositories (useful to easily mount development environments where the whole infrastructure could not be present). This pattern brought not just execution distribution but development distribution. Development could be better organized in different teams working in an asynchronous manner thanks to the inherent decoupling capabilities of this pattern. An interesting reference of this pattern is available at http://www.skyscrapr.net/blogs/solution/archive/2006/08/07/262.aspx. But MVC was just the beginning, because since the middle of nineties a series of books appeared to classify and organize many other architecture patterns. We must merely mention and recommend the POSA books (Patterns of Software Architecture), Sun’s Core J2EE Patterns, Martin Fowler’s series and, -with the launch of .NET - the MS Patterns and Practices guides. (Which include an interesting, ready-to-use set of application blocks, see Frameworks.) For more information visit http://msdn.microsoft.com/practices/

Figure 2. The MVC Pattern, as explained in MS Patterns & Practices' book "Enterprise Solution Patterns"

· Anti-patterns. A counter-concept grew in parallel with the concept of patterns. If a pattern is seen as a best practice, an anti-pattern is a worst one. There is an infamous common anti-pattern, which aspiring architects and junior ones apply all the time: that of over architect all and every software component. This is commonly specially seen in the need of adopting immediately the new version of everything without actually considering if its benefits are helpful. Perhaps with the misconception that doing so will provide a comprehensive, easy to change architecture in some near future. But experience is showing that the opposite is happening - nobody wants to touch unnecessarily complex solutions so they remain “as is” until they are completely replaced. For a discussion about this, we suggest this article http://www.skyscrapr.net/blogs/solution/archive/2006/08/28/282.aspx.

· Frameworks. In a remarkable effort of enabling large scale software production, a variety of component blocks (better known as frameworks) appeared. There are frameworks to solve the gap between the domain object model and the relational database schema (called Object/Relational Mappers); there are other ones intended to achieve a clean MVC componentization; and recently, a new generation of dependency-injection frameworks is dominating the scene. Dependency injection allows a component to not to be responsible for knowing what its dependencies are, it just has to know which interface they expose. Thus, any tier change will not impact on its associated classes, because they don’t know each other directly. The undeniable success of dependency injection frameworks coined a reputation for them as lightweight (application) containers, in opposition to heavy, all or nothing solutions. There are some other specific purpose frameworks: integration, monitoring, and so on. These all share one concept: to keep developers focused on business logic (functional requirements) instead of cross-cutting aspects like security, manageability, and other non-functional requirements.

Emerging Architect Roles

The considerations of economical changes like globalization and technological achievements like the Internet’s impact 0n the digital economy, pressed for formalizing software architecture as a discipline.

Although there is not yet a definite agreement in the distinct roles, we can sketch three major personas:

· Infrastructure Architect. These define the platform and other environments (hardware, basic software) to provide for business applications’ high availability. They must also work with developers to define mechanisms and standards that allow applications to achieve the security, reliability, manageability, transparency, and policy compliance essential to the modern business. It’s expected that the natural evolution of a senior IT professional is an Infrastructure Architect.

· Solutions Architect. These are responsible for the design of one or more applications or services within an organization, usually within the scope of a division (and for that reason also known as Application Architect). Examples of such applications are: Internet banking, companywide knowledge sharing portal, and distributed point of sales applications. A senior developer is a good candidate to become Solutions Architect.

· Enterprise Architect. Their job is to keep the business and its IT systems in alignment. They strive to maximize the return on IT investment by making sure that IT spending is prioritized towards business opportunity, and by optimizing the impact of investments across the organization’s portfolios of services, resources, projects, and processes. They must be a bridge between business leaders, development, and operations to ensure that mutual understanding is achieved, goals are realistic, and expectations are properly managed. Enterprise Architecture is about the big picture — how people and technology work together to produce world-class, long-term results. For that reason, this persona is also referred as Strategic Architect. What is expected is that a Solutions Architect or Infrastructure Architect becomes Enterprise Architect.

What Software Architecture worry about nowadays

Recent years have been really challenging for software architecture. An elemental concept like service-oriented components (and its, as time goes by, more winner implementation: the Web Services), gave place to a whole enterprise strategy known as Service-Oriented Architecture (SOA). SOA has as a goal the complete connection of the business application portfolio.

Figure 3. A Service-Oriented Architecture as told in the MS Architecture Journal (January, 2004)

Former silos like company CRM, ERP, and every line of business (LOB) application, are expected to enable their functions to the others for synergy and mutual profit. The SOA challenge is scattered in five major problems to address:

· Federated Identity and Access: How to manage the authentication and authorization systems in a centralized way, available for every application? Once the user logs in, how to propagate his identity to every service? How to treat external customers with respect to internal users? As just another role or maybe a completely different policy should be considered?

· Federated Data. How to keep the distributed repositories synchronized? How to gently gather enterprise entities by data aggregation? Which levels of redundancy are reasonable? How to deal with offline situations?

· Business Processes. Service-oriented components are granular pieces combinable in business workflows. Thus, every service could be seen as an activity to be executed in a definite order and upon definite conditions. The workflow engine becomes a sort of infrastructure piece in a SOA.

· Service-oriented components. There are four tenets that the pieces must comply with, to meet the SOA goals: explicit boundaries, autonomy, contract sharing, and policy-based compatibility. Those premises are better discussed at http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnbda/html/SOADesign.asp.

· Integrated User Experience. What does an SOA UI look like? There is a new range of UI frameworks around the concept of composed applications. We can find examples of them in CRM solutions and Web portal engines, where the UI is built through a combination of simpler, connected UI components.

The MSDN Architecture Center provides a complete reference about these capabilities: http://msdn.microsoft.com/architecture/solutions_architecture/default.aspx.

Where Software Architecture Goes from Here

While now concepts like patterns and SOA became or are becoming mainstream, software architecture continues evolving and expanding to new spaces. Because of space, we cannot discuss some other software architecture trends which build on SOA, like model-driven architecture (MDA) or software factories, but you can find more information at http://msdn.microsoft.com/architecture/factories/default.aspx.

However, there are two particular topics, not yet massively embraced, but watched very closely by the industry. (Usually, the industry is interpreted as the most important companies, IT analysts, and global system integrators.) They are:

· Software as a Service (SaaS). A new software delivery model, where companies don’t really hold their line-of-business (LOB) software bits, but only its right of use. That way, a new concept of software provider emerges (the so-called SaaS provider). Clearly, from the enterprise perspective, the inclusion of such software implies a certain impact. How to combine an SaaS application, for instance, in the company’s SOA? How to manage identities, workflows, and so on? From the provider perspective: a multi-tenant issue arises. If the provider is renting the software - its infrastructure -, to more than one enterprise customer, how can they enable further customization? Consider as examples various database schema; country policies that impact business processes, and other customer-specific modification. Perhaps even more pertinent, how to scale the environment for a growing number of tenants? The MSDN Architecture Center granted this topic its own space: http://msdn.microsoft.com/architecture/saas/default.aspx.

· Web 2.0. Another area of architecture research is how to get the most of the writable Web, Web based on participation. We talk about the Web ads, blogs, wikis, and other implementations. Those participative applications have existed for a while. The point is how companies can benefit from them, merging these kinds of community applications into their enterprise architecture. How to offer “the long tail” of those goods and services, each of which individually may not be the most wanted (possibly the least), but surely all of them together are becoming important in terms of revenue.

Conclusion

Some pundits wonder if being an architect is a condition they are born with or if it’s something acquirable with discipline and practice. In Microsoft, at the Architecture Strategy Team (AST) we are convinced that being an architect is a condition you can gain. SkyScrapr, http://www.skyscrapr.net/, is a community space for aspiring architects to share ideas, common knowledge, experiences, and - most of all - to discuss architectural issues.

Here we have reviewed how software architecture evolved from what software engineering was realizing about its existence.

The first software architects were de facto architects, in the sense that nobody officially granted them such titles. It was just a common perception, a sort of consensus.

But now software architecture is leaving behind its alchemist stage to become a real scientific discipline. Microsoft is contributing with the generation of a common space, an architecture collective community to make this real.

Architecture Best Practices

diegumzone — Mon, 30 Oct 2006 05:42:00 GMT

In "Last Call To Design Patterns" we described design patterns as "reusable solutions for frequent problems". It's all about thoughtful approaches to avoid common pitfalls

And, actually, Patterns are just one of a set of disciplines which help us to achieve software easy to understand and maintain. But, as PhD. Joe Hummel states in his seventh installment of his series "Architecting Smart Client Applications" on "Architectural Best Practices", best practices come at many levels (statement, method, class, architecture, process)

Despite, as Hummel says, "nothing beats experience" as the best teacher for best practices, he offers an awesome sets of resources and suggested readings, books and links to get the walk shorter

And there's more, because then the author addresses seven improvement areas and discusses each of them in further detail. They are

Security thru Threat Modeling. Which are our application vulnerabilities and how much exploitable are they?
Improved Design with Design Patterns. How can we avoid reinvent the wheel in order to solve already solved problems?
Design for Performance, but without using Correctness as an afterthought
Predictability (of bottlenecks or other aftermaths) and Application Behavior Insight with Instrumentation
Adequate Usage of Debug Features without interfering with the Release build
Proper Diagnostic of Exception Causes with a Correct Exception Handling
Smart Documentation as automated as possible

The author explains the mindsets behind every improvement area and actions to take, showing how Visual Studio 2005, Windows Management, Instrumentation (WMI), the Microsoft Enterprise Library and many other third parties tools (Log4Net, NDoc, etc) can help us to apply best practices painlessly

You can spend your time just coding, being that way a developer

Or you can also learn in greater detail all .NET APIs, CLR policies for security, threading, memory usage, being that way a senior developer

Or you can watch this webcast, learn about best practices, apply them consciously wherever they are necessary, being that way a respectable Software Architect!!

Why to be satisfied with less?

Come on, click here and raise your bar

Best Practices for Developing N-Tier Applications

Passing Data Between Layers and/or Tiers

diegumzone — Thu, 26 Oct 2006 08:34:00 GMT

While we were commenting some high-level strategies for data-access in a previous article, we mentioned a popular pattern used to interchange information between layers or tiers. We are talking about the Data Transfer Object (DTO) pattern. As the MS Patterns & Practices' book "Enterprise Solution Patterns" states, this solution strategy helps to reach

Reduced number of remote calls
Improved performance
Hidden internals
Discovery of business objects
Testability

But, because nothing is for free in this life, at a cost of

Possible class explosion
Additional computation
Aditional codding effort

Is there any way to mitigate the risks, while still reaching its benefits? The .NET platform answers this fundamental question with Typed-DataSets: collections of custom classes backed as ADO.NET's DataSets. Technically speaking, Typed-DataSets are extended DataSets ready to work specifically with a specific type, being able to validate we aren't using anything but such type in compile-time

So, what we usually express like this, working with ordinary, untyped DataSets

//-- Untyped DataSet
string sCoName =
oDs.Tables["Customers"].Rows[0]["CompanyName"].ToString();

We can abbreviate and validate against the DB schema at compile-time with typed DataSets with a sentence like

//-- Strongly typed DataSet
string sCoName = oDs.Customers[0].CompanyName;

As you can see, there's no need to lookup tables, because a typed-dataset's called Customers is actually a table; there's no need to explicitly access Rows or Columns through indexers, because we have available properties (like CompanyName in the above example) with the same name and type as DB table columns

Because they are DataSets, typical features like filtering, sorting, searching and other powerful DataSet capabilities are still available at no charge. But best of all, Visual Studio 2005 provides facilities for creating Typed-DataSets directly from DB tables, just by dragging and dropping them from the Server Explorer

Furthermore, Visual Studio 2005 creates for us a Table Adapter: a Data-Access layer component which moves data back and force between the Data Tier (i.e. the Database) and the Typed-DataSet. There are TONS of coding time saved because Visual Studio 2005 generates, by default, basic CRUD (for Create-Retrieve-Update-Delete) methods when generating the Table Adapter for us. We can, in turn, add our own specific data-access methods like GetCustomersByProvinceId(), etc

For those who believes I could be exagerating a little, I would like to invite them to watch Brian Noyes's webcast "Implementing a Data Access Layer with the Visual Studio 2005 Dataset Designer". Brian, solution architect from IDesign, is a MS Regional Director, author of several books and magazine articles on .NET applications

I also recommend the MS Patterns & Practices' "Enterprise Solution Patterns" chapter called Implementing Data Transfer Object in .NET with a Typed DataSet

Enjoy it!

Data Access Strategies

diegumzone — Tue, 17 Oct 2006 08:34:00 GMT

We have seen in the post about 3-Layer architectures, that the Data Access Layer isn't the persistence repository, but a set of strategies for accessing it

The challenge you as an architect have to face when designing this layer is multiple:

How much possible is the RDBMS being replaced for a competitor? This possibility is usually low on traditional enterprises, but on independent software vendors (ISV) and other software companies is frequent the need for developing a solution compliant with several RDBMS -Oracle, IBM DB/2, MS SQL Server, MySql- in order to easily accomodate to what the customer already has
How frequent can the database schema change? As the business evolves and the application needs to consider more data, the possibility increases
How can we be sure that incoming requests from the business layer have the user already authenticated?
How can we design a layer reusable from different applications?
Are we accessing just one database? If not, how to guarantee integrity in multipart transactions? (NOTE: we discussed about Two Phase Commit here)

In his sixth session, Ph.D. Joe Hummel offers his guidance in order to better address these topics, with an approach based on Design Patterns like the Data Access Object (usually mentioned as DAO), an agent which hides the complexities in the conversation with the repository (connectors, connector pools, tables, commands and possibly DataSet and other mid-level components). The DAO at the Data-Access Layer, interchanges information with the Business and upper layers thru Data Transfer Objects (DTO)

Hummel, as usual, doesn't imposse his solution but just shows some possible answers, explaining design decisions to take into account in front of different scenarios. Some of them:

Should we design our DTOs reflecting exactly our business entities? What happens later with reusability?
Should our data-access layer expose use case-driven, high-level methods, or the typical per-table CRUD methods? (for Create / Retrieve / Update / Delete)
Can we apply Dynamic SQL directly from the application? What about security, performance in such case? Eventually can we call stored procedures? So, what if we need a data-access layer compliant with several database engines?

Together with data-access best practices, Hummel analyses what architects did in three different case studies. But he also shows examples of SQL injection attacks and how to protect from them

Before finishing, the presenter provides recommendations for those who wants to design a data-access layer easy to change as new applications appear or as database schema changes

So, don't stay there looking this, click below and watch now

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 06 of 15): Designing the Data Access Tier

After finishing, you are also invited to visit the Data Access knowledge base at the Microsoft Solution Architecture Center

3-Tier, 3-Layer, MVC: a Trio of Famous Trios

diegumzone — Mon, 09 Oct 2006 07:58:00 GMT

Contemporary applications are being based on three popular architectural approaches. They are

3-layered architecture
3-tier architecture
Model-View-Controller architecture

There exists certain degree of confusion between all the three approaches. Mostly the first two are often referred as if they were the same one (see at Wikipedia). This can happen, possibly, because the three approaches aren't antagonistic. Actually, is pretty possible to find applications where the three are present. So let's dedicate some words to each of them

3-Layered Architecture

This approach implies a division of responsibilities in logical components. They are:

Presentation, where input forms and results are rendered
Business, or also Domain Logic, where core application logic lives. Here it's all about business nouns: Customers, Invoices, Purchases, etc. No explicit references to rendering mechanisms or persistence ones are made here
Data Access, where all those concerns related with persistence mechanisms (database connections, tables, records, etc) take place

Although a physical distribution of these or other application components can arise, this is not mandatory. Actually the benefits this architecture style brings are maintenance and reusability

Maintenance, because every layer comprises a set of few, cohesive APIs (the Presentation layer, APIs like WinForms, or ASP.NET, maybe Atlas; the Data Access layer, possibly ADO.NET, System.Xml; the Business layer probably can be almost agnostic of platform APIs, except the basic ones like Collections, etc)

Reusability is possible as we can add a new presentation layer for mobile devices, change the persistence mechanism by another database, possibly some static data in XML; but changes in one layer shouldn't impact on the others

For a deeper discussion on 3-Layered Architecture, I suggest the chapter ad hoc at the book Enterprise Solution Patterns (MS Patterns and Practices): http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpatterns/html/ArcThreeLayeredSvcsApp.asp

3-Tier Architecture

In this approach, we privilege a physical division of activities. Let's see:

Client (aka Front-end, Channels), consistent in a set of different hardware and software infrastructure where the application user interface (UI) can be executed
Application Server (aka Middleware), ranging from just one server up to a farm of them, where client requirements arrive through transport and message protocols (HTTP, SMTP, SOAP and other XML-based, etc)
Back-end, a set of heterogeneous supporting infrastructures. We can find examples like databases (for persistence ends), or complex legacy systems on a mainframe infrastructure

The application server here plays a key role as a concentrator of low-level services (communication, security, etc), thus joining different channels in their access to enterprise back-ends

This approach brings Scalability, Centralized Security and Fault Tolerance. A better explanation of this approach is available in the same book, at http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpatterns/html/ArcThreeTieredDistribution.asp

Model-View-Controller

We have already reviewed this behavioral architecture pattern at Starting with Model/View/Controller (MVC) Architecture Pattern (http://www.skyscrapr.net/blogs/solution/archive/2006/08/07/262.aspx). In brief words, this time the three components are

The View, although it seems that we are talking about the Presentation layer of the 3-Layered architecture, or the Client of the 3-Tier architecture, this version of view just carry presentation logic without event handling. Such later responsibility belongs to
The Controller, a component which receives Actor actions thru the View and motivates System responses in the same way envisioned in the Use Case document (a two column document enlisting stimulus/responses). These responses almost always involve
The Model, the status of the system, its business entities and the business rules which govern itself

This pattern is very useful to comprehend and implement behavioral aspects of the user interface, and its relationship with the rest of the system. It permits keep low the coupling between UI technologies and business logic together with persistence mechanisms. A deeper discussion is available at http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpatterns/html/ArcThreeTieredDistribution.asp

Conclusion

As said above, these three approaches allow us a better understanding and organization of components. Both logical and physically speaking. Although they help us gain different features like Reusability or Scalability, they can perfectly be present in a same implementation

Layered Applications: Let's Talk About Business

diegumzone — Mon, 02 Oct 2006 08:12:00 GMT

I remember a time when applications were just end to end programs, collections of lines of code with no distinction between presentation, domain logic and data access. Such kind of applications is remembered as spaghetti code

Fortunately nowadays enterprise applications are made in a better organized way: Layered Architectures helped reach that goal, separating in a clear and clean way the presentation logic from the domain logic, and at the same time, from the data-access code as well

Some month ago we started commenting a webcast series on Architecting Modern Applications, hosted by PhD Joe Hummel. This time is the turn of the Business Layer. In his fifth webcast, Hummel starts by revisiting the MVC pattern his series is about, showing where a business tier fits in the holistic picture

Then, he explains the Business Layer in depth, the need for it and the expected benefits (no, I don't gonna tell you: I want to encourage you to watch the webcast). But wait, because there's more

It follows an examination of the business tier in three case studies, and it's amazing how different teams implement a same idea in different ways, emphasizing different features in each case. Hummel explains each project background, showing how the application executes, some implemented code samples and, the most important, explaining the pros and contras of each approach

I strongly recommend you to check the three cases and think what you would take of everyone

The webcast finishes with a revealing discussion about Application Frameworks. Because developing enterprise applications is hard and critical issues arise, frameworks aid to speed development up, reaching higher production rates

Particularly two wanted cases are covered

Object / Relational Mappers, those are, frameworks to solve the impedance mismatch between business objects and relational tables. Here you'll know some of available ones for the .NET platform
Rocky Lhotka's Component-based, Scalable, Logical Architecture (CSLA), a very famous framework, used in numberous world class projects, available for different versions of .NET framework and other platforms, and analysis material of Lhotka's Business Objects books series

Surely we will devote some space to discuss a little further both and other kinds of application frameworks. In the meanwhile c'mon, join us and let's watch Hummel's

MSDN Webcast: Architecting Desktop Applications with 2.0 (Part 05 of 15): Designing the Business Tier

Aims and Means of Asymmetric Cryptography

diegumzone — Wed, 13 Sep 2006 01:49:00 GMT

Usually we tend to center the concept of Authentication to mere users, through and exhibited password as a credential

But beyond the user, how to be sure about authenticity of other assets? For example, how can we be sure about, once the user is authenticated, every received message, claiming in its header that it comes from his session is not a fake message created somewhere else (another user, a BOT, ...)? Even being originated from the expected user, what does guarantee us that the message wasn't change in its walk toward the server?

I'll explain this risk better: an always present threat in networking is the so-known Man in the Middle. Someone intercepts our message, filters it by changing sensitive parts (a transfer amount, a destination account, ...) and resends his altered version. The server receives it, and because it came from a proven identity session, it accepts it without noticing it was changed

How can we deal with this reality?

Public-Key Cryptography (aka Asymmetric-Key Cryptography) comes to rescue us. This algorithm works this way:

The issuer, before sending his message, applies to it a function consisting in calculating a digest based on the message itself (a hashing value, a checksum, etc)
This digest is encrypted by applying a key the sender owns, only. This key is well-known as the Private Key
The encrypted digest is then added to the original message, together with a key the receiver will need in order to decrypt it. This new key, publicly available, is consequently known as Public Key
The receiver, so, calculates the digest and compares his result with the decrypted received digest

Yes, the man in the middle could spy the message but he can't alter it in any way: if so he did, the digest would change and he doesn't have the private key to encrypt the new digest. So the conclusion is that every message, with both calculated and received digests matching, belongs to the original user and it's unadulterated. This algorithm, so, is useful to avoid two threats: message repudiation by the original user (for instance, after issuing a purchase) and tampering by anyone in the middle (to avoid message interception, there are another countermeasures)

Asymmetric-Key Cryptography examples are anywhere, even though we don't notice that. For instance, .NET's Code-Access Security (CAS) capability permits us, among lots of other features, guaranteeing that an assembly can't be replaced. How? Pretty easy:

The assembly provider has his private key. Whit that key he digitally signs the assembly
The assembly, that way, contains a digital signature based on its name, version and optionally culture information. This signature is encrypted with the private key and enclosed, together with the public key, into the assembly (which becomes a strong-named assembly)
When, during execution time, the CLR loads the assembly in order to execute it, first it calculates the assembly signature based on assembly evidences (its name, etc). Then, with the enclosed public key, it decrypts the encrypted signature and compares it with the calculated one
If they don't match, a SecurityException will be issued. Thus, in the case that anyone other than the original provider changes the assembly, be sure that the signatures won't match... with the solely exception of...
Yes! Except the case the fake provider uses his own pair of keys (private and public). But .NET's security strategy prevents that thru the Microsoft .NET Framework 2.0 Configuration Tool (Administrative Tools). That tool allows is to provide which public keys will be trusted
That way, we just need to load there the public key of our trusted provider

Another example of Asymmetric-Key Cryptography usage, more agnostic, is present in WS-Security specification, applicable, for instance, thru X.509 certificates. This is available in Windows Communication Foundation (WCF) as well in the transient Web Services Enhancements (WSE) version 3

Finishing this article, I want to mention a variation of the Public-Key Cryptography, intended not for non repudiation purposes but for information disclosure avoidance. The variation consists in using -the sender- a public key to encrypt the whole message. The receiver, in this occasion, is the only who owns the private key, necessary to decrypt the message received. This variation avoids unauthorized inspection of incoming messages, but doesn't prevent spoofing of the sender identity

How Sure Are You About Security?

diegumzone — Thu, 07 Sep 2006 07:48:00 GMT

Even though it´s surprising, an important number of architects don't worry enough about security aspects

Talking with some of them, they considered that Security is a topic so complex -they are right in this appreciation- that developers don't have to care about it, just delegating its concerns to infrastructure pieces like firewalls and directory servers

I admit that keeping developers focused in business logic is always desirable, however I consider that security infrastructure, by itself, is an important part of the security strategy. Surely not the only one

My grand mother always said me "we can't trust in anyone anymore" and I didn't understand why she thought like that. Until I started making my first enterprise web applications and suffered my first attacks from unknown people. Those attacks were categorized in what is known as STRIDE

Spoofing identity. An example of identity spoofing is illegally accessing and then using another user's authentication information, such as username and password
Tampering with data. Data tampering involves the malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet
Repudiation. Repudiation threats are associated with users who deny performing an action without other parties having any way to prove otherwise—for example, a user performs an illegal operation in a system that lacks the ability to trace the prohibited operations. Nonrepudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package
Information disclosure. Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it—for example, the ability of users to read a file that they were not granted access to, or the ability of an intruder to read data in transit between two computers
Denial of service. Denial of service (DoS) attacks deny service to valid users—for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability
Elevation of privilege. In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself, a dangerous situation indeed

Because one of the missions of application architecture is dealing with complexity, particularly the complexity of dealing with such kinds of atacks, there exist a technique called Threat Modeling, consisting in acting like the enemy, thus anticipating his/her attacks in order to avoid them by opposing countermeassures

How to start learning about security topics? In his fourth presentation, Joe Hummel requests just one hour and half of your time to make you learn about security without assuming you have any kind of basic knowledge. As usual, he starts from the beginning, telling you about the security tenets and defining the most important terms, like Principal, Identity and Role. Benefits and disadvantages of using embedded security schemas like Windows', versus coding our own schema. Considerations when storing passwords or any other kind of secret (private information). .NET support for securing applications, different choices with pros and cons analysis

Architecting Desktop Applications with 2.0 (Part 04 of 15)

Once you finish, I suggest you continue your exploration with what Patterns & Practices has to say about Threat Modeling practices

Threat Modeling Web Applications

Enjoy it!

An Old Antipattern: "Too Much Architecture"

diegumzone — Mon, 28 Aug 2006 08:49:00 GMT

At least in Software Engineering, but I guess the same applies to other sciences, there are ideas, concepts and paradigms easy to understand, but not so easy to implement in practice

I remember, for instance, I understood very quickly OOP. It was pretty clear that Bird, Dog and Cat were subclasses of Animal, and that SiberianHusky or Labrador where subclasses of Dog, while Parrot was a subclass of Bird

But then I was unable to write a piece of OO code that takes a number and tells if the number was even or odd. I mean, I did it. But I made a one-class application with a method, not so different of a simple C language function bool IsEven(int a)

I have no doubts about the need of OO and its benefits over structured programming. I want to highlights that at the same time OO design is by far more complex

So Design Patterns came to the rescue, with a toolbox of pre-molded components, still unfinished from the point of view of our application, but with a very clear separation of roles and well established relationships between participant classes of every pattern

First, I borrowed the GoF book. Then I bought it. I read all the more than 20 patterns, Creational, Structural, Behavioral... I understood everything again. I figured out scenarios where to apply each one of them...

And again when I had to start... Wow... Again my mind empty. It seemed clearer at the book

After that first stage, I entered to the next one: try to make patterns fit everywhere. The more patterns in, the better... I made beatifuly complex applications I was unable, in best cases, to explain. In the rest of cases, I was unable to finish them

Of course, again, the problem wasn't Dessign Patterns, but how easy was for me falling in the temptation of abuse. Like with any medicine: who exagerates the dosis, turns the remedy into a new disease

Nowadays I see two other adictions:

The need to adopt immediately the new version of everything (.NET framework, Spring framework, Eclipse, etc) without actually considering if its benefits are helpful for us (in several cases, without knowing which those benefits are. I insist: I'm not against modernisation but the fact of forgetting the last instance business goal (the forest) while being so concentrated just in a new technology (the tree)
The other adiction seems to be Object/Relational Mapping (or O/R-M). As with OOP, design patterns, etc I repeat over and over: I'm not against O/R-M! What I want to mean is: if then, as I saw in so much forum threads, yo will be wondering how to do to avoid loading a complete object graph of nested elements just to show a simple table in an ASP.NET page, check how ready you were to get on O/R-M and if it's true that nowadays mappers are the solution you need or just a new problem you gotta solve

I want to show a dialogue kept in an architect forum at MSDN: please click here

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=630361&SiteID=1

The post is about problems derivated of O/R-M abuse. Just an example in thousands about how "easy" is to choose "the difficult one"

Fighting Against Coupling: a Moment for Reflection

diegumzone — Mon, 21 Aug 2006 10:12:00 GMT

One of the most recurrent problems we have to face, as aspiring architects, is the problem of dealing with highly adaptable applications for different environments

For instance, we need to build an application able to access a DB/2 database in one environment, an Oracle database in another one, and an XML file in a third one. The data access logic in the two first cases is pretty similar, but the ADO.NET classes are not the same on each case. The XML file need also special logic (not based in SQL)

The problem with the command new is that we need to explicitly write the name of the class we want to instantiate. So we need to put different names on each case and recompile the application before deploy it

But, thus, the application could drive to an untenable maintenance. This is a limitation of Static (explicit) Instantiation. Fortunately, .NET provides a mechanism that enables another level of object creation: Dynamic Instantiation

Dynamic Instantiation is possible thanks to a feature called Reflection. Reflection permits us to see the execution environment as first class objects. That way, we can load assemblies (for instance, taken their name from strings), we can instance classes located inside them (again, taken their names from strings or any other indirect mechanism)

So, let's go ahead and start building highly adaptable applications

But… wait… One moment… Strings, ha? So… where can we put those strings? That's a very good question that everybody ask. And be sure that most of them considers that there's no answer for that question, so they build, first of all, some infrastructure classes to support configuration properties, in order to read them while loading the application

This is an unnecessary step, because .NET 2.0 comes with built-in support for configuration settings. This support, in .NET 1.1, was available through the Configuration Management Application Block (CMAB), later called Configuration Application Block in the Enterprise Library 1.0

But in .NET 2.0 all that functionality is embedded and extended in the Visual Studio 2005 IDE. In fact, every project can define its own execution settings. Application settings can be thought in two levels

Application-bound: typically connection strings, timeout intervals, server names, etc. In general terms, parameters available for every user (not dependent on him/her). Usually this parameters can vary from an installation to another one. But, in each one, they vary very little
User-bound: this kind of settings are kept in a per-user basis. Examples of this are: color and layout preferences, last five issued queries, etc. In few words, user settings are suitable to keep the last session state along different executions. Thus, high changeability is expected for these settings

What .NET 2.0 does with what the user loads as settings in Visual Studio 2005 is to create on the fly a class called Settings (in the project namespace), containing all the parameters defined by the user as read/write properties. Although usually properties are defined as strings, we can specify the type of everyone. Every serializable class can be the type of any property to be set

We can change these properties during execution, and save all the bundle thanks the method Settings.Default.Save(). Application-bound properties will be stored in the same directory where its project assembly is, under the name

<assembly name>.exe.config

On the other hand, user-bound properties will stay at

C:\Documents and Settings\<username>\Local Settings\Application Data\<assembly name>\user.config

So, what we have learned so far is that we can, via application settings, indicates classes to be dynamically instanced by Reflection

So far so good, but if you don't, I have a question: if the application won't know until runtime which class will be instanced, how can we, at development time, invoke methods on that still unknown class!?

Without answering this question, all the benefits of using Reflection to avoid coupling are useless. But, once again, fortunately there exist a technique to address this issue: Interface-based programming

Interface-based programming, aka "Programming against Interfaces" implies to define a clear set of properties and methods that must be present in the class to be known during execution. That's the idea of interfaces: not concrete logic but placeholder to be filled with concrete logic

If you were wondering for a longtime about why interfaces exist, I guess this is a transcendental moment in your career. Welcome to the Truth! Say goodbye to your old folks in the club of people who don't know why interfaces exist. Have a nice stay in the club of people who already discovered why interfaces exist

So, beyond jokes, we can code the application in order to talk with the defined interface and, during execution time, access to the application settings in order to get the concrete class to be instanced via Reflection

Bibliography usually call interface implementers as "pluggable components". Now…

How do you see if we check again all of these concepts, but in a deeper level, including demos? It's great, isn't it?

Join this webcast, the third in the series of Architecting n-tier applications with Joe Hummel

Creating Dynamic and Configurable Applications

Hasta la vista

Two-Phase Commit (2PC): Coordinating Transactions in Distributed Environments

diegumzone — Mon, 14 Aug 2006 11:11:00 GMT

There was a time when applications were isolated as a common issue, and having each one just one repository was usual

Sometimes, we needed to update diverse records to the repository, let's say a purchase order header with its purchased items. Those times, it was necessary that all that business movement was made in an "all or nothing" manner. That is, every record should be saved, or elsewhere no record saved at all was the best contingent option (raising an exception to advice that something went wrong and the business movement couldn't be saved). The fact is that, saving some records and leaving the rest unsaved drives to inconsistencies

So, to reflect such "all or nothing" policy, the concept of transaction emerged. Transactions are said to be acid :-) in the sense that they are

Atomic: a transaction must completely occur, or must not occur at all. As we commented before
Consistent: a transaction is the transition between two consistent states in the application and/or its data
Isolated: a transaction is independent of other transactions occurring at the same time
Durable: the state of the application or its data after a transaction occurrence, only can be changed by other transaction

Up to here, nothing uncommon. In the context of single back-end solutions (i.e. a database), if the back-end is transaction-enabled, applications just demarcate where the transactional scope starts and where it finishes. Saving for them, if abnormal conditions arise, the power to roll back a transaction to the former consistent state

But, nowadays, applications aren't isolated anymore. Today we encounter, as an usual feature, that enterprise applications are built upon building blocks. Let's imagine, for instance, a call center application able to add or remove services to a customer account, resend bills or invoices, accept different kind of payments (credit card, debit, banking transfer, etc)

Call center applications are frequently "composite application": they expose consolidated GUIs from disparate applications, and invoke several back-ends (either directly, or through a middleware)

So, imagine a customer has his/her account blocked (no services available) because unpaid bills. The customer calls the call center, wanting to correct his situation in order to get services back. The employee retrieve his debt, tells the customer and offers available payment mechanisms

The customer choose bank account transfer so...

A debit on his account must be made (thus, online access from the company to the bank must be presente)
A credit on the company account, also (implying online access from the company to its bank)
A payment record (through the collection system)
The restablishment of services, that could imply posting commands to several back-ends (cellular phone, internet, cable TV, etc)
Countable movements (accessing the accounting system)
Auditing records (through the auditing system)
...

In the past, such kind of operations were asynchronous. I mean, the company accepted the payment as conditional, and updated every back end through batch processing. In the meanwhile, the customer still didn't get his services back until the last critical back-end was succesfully updated

Because of that, compensation processes had to be considered for the sack of consistency

But, why not to think in including everything in a transaction? Because when just one back-end is involved, the transaction scope is managed by the back-end itself. But when, as in this case, several back-ends are involved, we need a superior instance able to establish a transactional scope, enrol the involved tiers and coordinate the transaction in the distributed environment

Fortunately when a problem is so common, the probability of finding a solution is greater. And that rule is met in this case: let me introduce Two-Phase Commit (2PC for short)

2PC is a standard protocol for transaction coordination in distributed environments. Thus, we can think in 2PC-enabled back-ends, ready to handle a transaction locally, but following directions from a foreign coordinator

For a deep explanation of Two-Phase Commit protocol, I suggest to visit this link http://en.wikipedia.org/wiki/Two-phase_commit_protocol

In the Microsoft platform, the Distributed Transaction Coordinator (DTC) is a Windows service capable to coordinate 2PC-enabled tiers (also known as XA-compliant resource managers). Here we have an interesting link to gain insight with MS DTC: DTC Developers Guide

From the point of view of .NET development, .NET 2.0 brought a new namespace, System.Transactions, which made transaction-oriented services coding easier than ever. That is, System.Transactions is an abstraction level between the application logic and MS DTC as an infrastructure component. One of the best features of System.Transactions, in terms of transparency, is that this API is intelligent enough to infer that more than one back-end is involved in the transaction, and thus involving MS DTC

I mean, the programming model is similar whether one only back-end participates in the transaction or we have several ones

You can start learning this facility by reading an article of MSDN Magazine:

.NET Matters: Scope<T> and More

Also, a deeper reference is here: Transaction Processing

As a final reflection, however 2PC protocol is thought for both EAI (intra organizational) and B2B (inter enterprise) scenarios, still it's supposed that in the later won't be massively present for a while

Starting with Model/View/Controller (MVC) Architecture Pattern

diegumzone — Mon, 07 Aug 2006 06:51:00 GMT

With the massive advent of Internet, mobility and other network technologies, distributed programming is more popular than ever and it's unimaginable the idea that stand alone applications can come back

They are gone

So immediately a coupling crisis appeared in distributed applications: how to avoid mentioning concrete technologies in order to keep the maintenance of distributed systems in acceptable levels of complexity. For instance, how to avoid code twice (or even more than twice) large portions of formerly desktop UI, if we need to add a web channel for home consumers, a mobile channels for executives during business trips, etc. How to provide a solution not tied to a specific database (SQL Server, Oracle, etc) or, even more, able to handle small sets of data via an XML-based repository

Model-View-Controller (most referred as MVC) is the name of one of the most successful architecture patterns, which address this issue. It consists in a separation of three application concerns in different logical tiers

The user interface (UI), that receives inputs from the user and exposes results. In this schema is referred as "the View", and it could be applied to the most basic text terminal, or the most advanced Pocket PC. The code of this tier deals with the specific available UI technologies

A tier were domain entities "live", and their status is kept, usually known as "the Model". It can be a database, an XML file or a whole mainframe system (accessible through communication technologies varying from propietary solutions to open standards like web services

And finally, a nexus between the View and the Model, capable to react to events from the View, transforming the signal in a request for the model. Clear examples of this: a button click motivates a purchase invoice printing. The tier which handles this transform is called "the Controller" and basically contains use cases logic

The first benefit of this decomposition is the fact that the View and the Model are no more coupled. And with this, we can append more channels to our application (ATMs, etc) with no impact in the data access logic. Or conversely, we can change or extend the data repository with, for instance, aggregation services, immediately available for every channel at the same time

There are several uncoupling degrees of MVC in practice. Still the View can stay coupled with the Controller or vice versa, and the same applies for the Controller and the Model

So the question, again, is… where to start from?

And the answer again is: from Joe Hummel

In his second webcast in the series "Modern Software Development: Use Visual Studio 2005", he starts showing how Visual Studio 2005, although being a very productive tool from the perspective both the developer and the business, it imposes "its" architecture. And architecture quick, easy to understand, but not so easy to extent

So he revisits the MVC pattern, unleashing there some popular GoF patterns embedded (those are abstract, low level patterns compiled in a book that is still a best seller; its author are known as "the Gang of Four" or simply GoF, and so the term "GoF patterns")

Hummel explains very clearly how these patterns enforce the whole MVC architecture, and applies them to the raw initial outcome that Visual Studio 2005 produces loosing, as the patterns go by, the coupling among the three layers

Still better, the author recommends when/where not to use them, in order to not to over design the application. This could increase unnecessarily its complexity… and its later maintenance

Hummel concludes by mentioning two MS application blocks to put this concepts in practice in a productive and elegant manner (unfortunately because of a matter of time, no demos are offered)

So, go for a coffee, seat comfortable, turn up the volume and start watching

Architecting Desktop Applications with 2.0: Design Patterns for GUI Applications

Enjoy it!

Last Call to Design Patterns

diegumzone — Sun, 30 Jul 2006 10:44:00 GMT

When planing the architecture of an application, the architect has a powerful set of tools available: Design Patterns

Design Patterns are reusable solutions for frequent problems, upon different contexts. The more you know about them, the more self-confidence you gain while doing your architecture. And possibly (I'm not saying probably, yet) the more robust your results

What is the risk when an aspiring architect recently knew about design patterns? Overarchitecture of his designs, felling himself obliged to apply the new acquired knowledge

A common mistake around this is considering that a solution which has design patterns applied is better than other which has less or doesn't have at all. Quantity doesn't imply quality. It's all about the opportunity to apply them when it's useful and relevant

So, taking into account this reminder, where to start?

There is a book that was a hit and established a "before and after" in software engineering: "Design Patterns: Elements of Reusable...". Its authors are also known as the "Gang of Four", or simply the GoF

Starting from this book wasn't bad, but in some cases drove to inadequate application of the concepts, because patterns there are very very fundational

I want to suggest another starting point, better focused in application contexts (web, smart client, SOA) and concerns (security, data access, etc), because applying GoF patterns to real world enterprise class applications is not an intuitive task (it requires patience to become experienced)

The place I say is "Patterns and Practices Patterns repository"
http://msdn.microsoft.com/practices/topics/patterns/default.aspx