| |
 |
|
 |
Ask the Expert about Aspect-oriented Programming
By Jeff Kempiners, Avanade
Compared to object-oriented programming or service-oriented architecture, aspect-oriented programming (AOP) is not a widely adopted concept – yet. But a host of factors are converging – from interest in the concept of enterprise service buses (ESBs) to companies’ standardization of their Web services initiatives, to new tools available in Microsoft Visual Studio 2005 – that soon may lead enterprise architects and application development teams to view AOP as a strategic approach, rather than an esoteric programming method.
Avanade already is helping customers take advantage of AOP for application architecture. We asked Jeff Kempiners, .NET Solutions Practice Director for Avanade Canada, for a high-level view of what AOP does, and how it can help the IT department achieve both technical and business advantage.
What is aspect-oriented programming?
What functions make good aspects?
Can you describe an aspect in use?
What makes AOP preferable?
So does AOP help developers do better work?
How does AOP impact enterprise architecture initiatives?
From a business standpoint, what’s the value in AOP?
What is aspect-oriented programming? |
|
| Jeff: |
AOP is based on the same principles of service-oriented architecture (SOA) – namely, isolation of business logic from core application logic. As with SOA, this isolation makes it possible to reuse code – and ensure consistent execution – as well as providing greater flexibility in programming.
The “aspects” in AOP are these reusable, core functions that can be applied across an application system. AOP picks up where object-oriented programming (OOP) leaves off, because it provides a way to program functions independent of the hierarchical constraints of an application’s structure. As a result, you can use the functions over and over again.
|
back to top
|
What functions make good aspects? |
|
| Jeff: |
Within an application, any service that provides a “helper” function is a candidate for an aspect. Field validation helpers, encryption helpers, authorization, caching, logging / instrumentation and exception handling are core functions that are excellent candidates for aspects. |
back to top
|
Can you describe an aspect in use? |
|
| Jeff: |
Let’s say that “GetCreditCardNumber” is a method by which an application will retrieve someone’s credit card information – and let’s say I would like to encrypt this method while the message is transmitted across a network. I could use an aspect to implement this encryption feature, and link it to GetCreditCardNumber with a piece of code called an “attribute.” The implementation of GetCreditCardNumber stays within the method, and all of the encryption is kept outside of the method.
Using conventional programming techniques, I could include the encryption inline with the business logic, and then refactor the encryption and decryption into “helper functions” so that these functions would appear as one line of code within “GetCreditCardNumber.” But I still would have to make this code sandwich the business logic to retrieve the credit card number. Once I start adding other core features such as tracing, logging, authorization and the like, the intertwined code for business logic and core functions starts getting much more complicated.
The aspect-oriented approach forces the action I want, but keeps the invocation logic outside the business logic, so that the implementation code stays “cleaner” overall. I can take things a step further and create an “aspect container,” or a single line of code that dictates which aspects are to be applied. Then I can easily modify the contents of the aspect container within a .config file to alter the behavior of my application methods without changing any code. For example, I can call encryption in production but turn it off in testing, for troubleshooting purposes. |
back to top
|
Software developers already have techniques for coding functions so that they are reusable. What makes AOP preferable? |
|
| Jeff: |
Unlike other programming techniques, AOP essentially takes a piece of code that provides a feature, and invokes it in a way that does not interfere with the business-logic portion of the code. Not only is code cleaner; AOP design starts with the identification of functions to be reused, paving the way for more efficient development.
In object-oriented programming, a developer defines a fixed hierarchy of elements that an object “inherits,” in order to provide specific, isolated functionality. This hierarchy might be successful in isolating some, but not all, of the features required. Since the whole purpose of introducing objects is to identify different concerns in the first place, the practice of isolating them as aspects is gaining momentum as a powerful technique to extend the usefulness and simplicity of the OOP model. |
back to top
|
So does AOP help developers do better work? |
|
| Jeff: |
Despite the incredible wealth of tools available today, software development still requires attention to detail. AOP can help reduce the potential for mistakes.
Even Microsoft has taken advantage of aspects to cut down on potential for programming errors: Its implementation of the [WebMethod] attribute in .NET automatically takes care of code-generation of the Web Services Definition Language (WSDL), the interface proxy and the .asmx “listener” on Microsoft Internet Information Server, eliminating possible programming mistakes or slight variations in implementation that can cripple a software project. |
back to top
|
How does AOP impact enterprise architecture initiatives? |
|
| Jeff: |
Well, in addition to the complementary relationship I mentioned between AOP and SOA, I think enterprise service buses (ESBs) and AOP are quite complementary as well. ESB puts standards in place to ensure that all messages within an ESB system adhere to some set of rules defined by the enterprise. AOP can add value by allowing these messages to be “plugged into” the system with no modification of the business logic.
For example, I might have a prerequisite that a message must raise an event to the ESB when the message is submitted. Other prerequisites could have to do with security, message types and formats, and each of these may be included in the aspect container that I provide to my development community to fulfill these prerequisites. If these aspects (and the associated aspect container) are part of the enterprise architecture, then the developer only needs to include the attribute indicating that a given method should participate in an ESB, and the aspect container will handle all the rest.
|
back to top
|
From a business standpoint, what’s the value in AOP? |
|
| Jeff: |
Using AOP can make life easier for the developer and encourages compliance with the enterprise architecture. But for IT management, AOP can offer gains in productivity and improvement in the area of governance – particularly where requirements for software implementation are difficult to manage and govern, and when training developers in these requirements is difficult.
With AOP, IT management can identify areas where governance and implementation “rules” can be applied using aspects, and publish those aspects to the development communities for use within all the projects of the enterprise.
|
back to top
|
|
|
|
|
