Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-24T02:25:36Z

Ncsueng: /* '''DRY principle - Data''' */

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

This article briefly explains how the DRY principle not only applies to code but also to data. It further describes how in some situations, violating the DRY principle is accepted for gains in areas where would not be possible without some way of duplicating information. In such situations, it is extremely important for the original source of information to be known.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Violation of the DRY principle
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, however, the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Stale Data - if data is duplicated, it needs to remain in sync with the source or it will become stale and no longer valid
* Overhead - in order for data not to become stale, it needs to be updated whenever the original source is also updated. This could increase the processing in order to maintain the data in sync
* Additional memory - data duplication usually means more memory to store and manipulate

==='''Scenarios where DRY principle is violated'''===

There are certain scenarios, however, where duplication might not only be acceptable but also desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production. Two such tools for management control that directly violate the DRY principle are [http://en.wikipedia.org/wiki/Subversion_(software) SVN] and [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS].

This is direct violation of the DRY principle since at any given time, there could be copies of the same file in different branches allowing developers to work concurrently in different areas of the code without affection one another. Developers can even work on different versions independently and merge them together at a later time.

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

This violates the DRY principle by copying data locally in order to achieve faster processing than would normally be possible by having to fetch the same data across the network or another slower location.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

This example of violation of the DRY Principle allows the developers to spent less time updating documentation every time the code is changed by allowing the documentation to be directly retrieved from the source code. This is in direct violation of the DRY principle as the same data/code now appears in two different locations.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known. In short, you should only consider data duplication if:

* It could potentially simplify the system without needing up-to-date or precise information, as in calculating a result at one point in time, where it might not be important to perform the same calculation at a different time with updated information.
* It will increase the system performance without greatly decreasing maintainability.
* There is benefit of being to access different versions of the code in time, or sharing between different developers so that the code throughput is increased, as in the case of source control tools.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==

1. [http://en.wikipedia.org/wiki/DRY The DRY Principle]

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

=='''Further Readings'''==

1. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html applying the DRY principle to writing computer code]

2. [http://reinholdweber.com/css/refactoring-your-css-styles-to-comply-with-the-dry-principle/ Refactoring to comply with the DRY Principle]

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-24T01:30:24Z

Ncsueng: /* '''DRY principle - Data''' */

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

This article briefly explains how the DRY principle not only applies to code but also to data. It further describes how in some situations, violating the DRY principle is accepted for gains in areas where would not be possible without some way of duplicating information. In such situations, it is extremely important for the original source of information to be known.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Violation of the DRY principle
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, however, the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Stale Data - if data is duplicated, it needs to remain in sync with the source or it will become stale and no longer valid
* More overhead - in order for data not to become stale, it needs to be updated whenever the original source is also updated. This could increase the processing in order to maintain the data in sync
* Additional memory - data duplication usually means more memory to store and manipulate

==='''Scenarios where DRY principle is violated'''===

There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production. Two such tools for management control that directly violate the DRY principle are [http://en.wikipedia.org/wiki/Subversion_(software) SVN] and [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS].

This is direct violation of the DRY principle since at any given time, there could be copies of the same file in different branches allowing developers to work concurrently in different areas of the code without affection one another. Developers can even work on different versions independently and merge them together at a later time.

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

This violates the DRY principle by copying data locally in order to achieve faster processing than would normally be possible by having to fetch the same data across the network or another slower location.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

This example of violation of the DRY Principle allows the developers to spent less time updating documentation every time the code is changed by allowing the documentation to be directly retrieved from the source code. This is in direct violation of the DRY principle as the same data/code now appears in two different locations.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known. In short, you should only consider data duplication if:

* It could potentially simplify the system without needing up-to-date or precise information, as in calculating a result at one point in time, where it might not be important to perform the same calculation at a different time with updated information.
* It will increase the system performance without greatly decreasing maintainability.
* There is benefit of being to access different versions of the code in time, or sharing between different developers so that the code throughput is increased, as in the case of source control tools.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==

1. [http://en.wikipedia.org/wiki/DRY The DRY Principle]

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

=='''Further Readings'''==

1. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html applying the DRY principle to writing computer code]

2. [http://reinholdweber.com/css/refactoring-your-css-styles-to-comply-with-the-dry-principle/ Refactoring to comply with the DRY Principle]

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-24T01:26:57Z

Ncsueng: /* '''How to determine when to duplicate data''' */

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

This article briefly explains how the DRY principle not only applies to code but also to data. It further describes how in some situations, violating the DRY principle is accepted for gains in areas where would not be possible without some way of duplicating information. In such situations, it is extremely important for the original source of information to be known.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Violation of the DRY principle
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

==='''Scenarios where DRY principle is violated'''===

There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production. Two such tools for management control that directly violate the DRY principle are [http://en.wikipedia.org/wiki/Subversion_(software) SVN] and [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS].

This is direct violation of the DRY principle since at any given time, there could be copies of the same file in different branches allowing developers to work concurrently in different areas of the code without affection one another. Developers can even work on different versions independently and merge them together at a later time.

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

This violates the DRY principle by copying data locally in order to achieve faster processing than would normally be possible by having to fetch the same data across the network or another slower location.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

This example of violation of the DRY Principle allows the developers to spent less time updating documentation every time the code is changed by allowing the documentation to be directly retrieved from the source code. This is in direct violation of the DRY principle as the same data/code now appears in two different locations.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known. In short, you should only consider data duplication if:

* It could potentially simplify the system without needing up-to-date or precise information, as in calculating a result at one point in time, where it might not be important to perform the same calculation at a different time with updated information.
* It will increase the system performance without greatly decreasing maintainability.
* There is benefit of being to access different versions of the code in time, or sharing between different developers so that the code throughput is increased, as in the case of source control tools.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==

1. [http://en.wikipedia.org/wiki/DRY The DRY Principle]

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

=='''Further Readings'''==

1. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html applying the DRY principle to writing computer code]

2. [http://reinholdweber.com/css/refactoring-your-css-styles-to-comply-with-the-dry-principle/ Refactoring to comply with the DRY Principle]

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-24T01:23:40Z

Ncsueng: /* '''How to determine when to duplicate data''' */

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

This article briefly explains how the DRY principle not only applies to code but also to data. It further describes how in some situations, violating the DRY principle is accepted for gains in areas where would not be possible without some way of duplicating information. In such situations, it is extremely important for the original source of information to be known.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Violation of the DRY principle
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

==='''Scenarios where DRY principle is violated'''===

There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production. Two such tools for management control that directly violate the DRY principle are [http://en.wikipedia.org/wiki/Subversion_(software) SVN] and [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS].

This is direct violation of the DRY principle since at any given time, there could be copies of the same file in different branches allowing developers to work concurrently in different areas of the code without affection one another. Developers can even work on different versions independently and merge them together at a later time.

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

This violates the DRY principle by copying data locally in order to achieve faster processing than would normally be possible by having to fetch the same data across the network or another slower location.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

This example of violation of the DRY Principle allows the developers to spent less time updating documentation every time the code is changed by allowing the documentation to be directly retrieved from the source code. This is in direct violation of the DRY principle as the same data/code now appears in two different locations.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known. In short, you should only consider data duplication

* If doing so will increase the system performance without greatly decreasing maintainability.
* In the case of source control tools, if there is benefit of being to access different versions of the code in time, or sharing between different developers so that the code throughput is increased.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==

1. [http://en.wikipedia.org/wiki/DRY The DRY Principle]

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

=='''Further Readings'''==

1. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html applying the DRY principle to writing computer code]

2. [http://reinholdweber.com/css/refactoring-your-css-styles-to-comply-with-the-dry-principle/ Refactoring to comply with the DRY Principle]

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-24T01:17:28Z

Ncsueng: /* '''Source Version Control''' */

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

This article briefly explains how the DRY principle not only applies to code but also to data. It further describes how in some situations, violating the DRY principle is accepted for gains in areas where would not be possible without some way of duplicating information. In such situations, it is extremely important for the original source of information to be known.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Violation of the DRY principle
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

==='''Scenarios where DRY principle is violated'''===

There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production. Two such tools for management control that directly violate the DRY principle are [http://en.wikipedia.org/wiki/Subversion_(software) SVN] and [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS].

This is direct violation of the DRY principle since at any given time, there could be copies of the same file in different branches allowing developers to work concurrently in different areas of the code without affection one another. Developers can even work on different versions independently and merge them together at a later time.

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

This violates the DRY principle by copying data locally in order to achieve faster processing than would normally be possible by having to fetch the same data across the network or another slower location.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

This example of violation of the DRY Principle allows the developers to spent less time updating documentation every time the code is changed by allowing the documentation to be directly retrieved from the source code. This is in direct violation of the DRY principle as the same data/code now appears in two different locations.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==

1. [http://en.wikipedia.org/wiki/DRY The DRY Principle]

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

=='''Further Readings'''==

1. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html applying the DRY principle to writing computer code]

2. [http://reinholdweber.com/css/refactoring-your-css-styles-to-comply-with-the-dry-principle/ Refactoring to comply with the DRY Principle]

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-23T20:22:30Z

Ncsueng:

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

This article briefly explains how the DRY principle not only applies to code but also to data. It further describes how in some situations, violating the DRY principle is accepted for gains in areas where would not be possible without some way of duplicating information. In such situations, it is extremely important for the original source of information to be known.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Violation of the DRY principle
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

==='''Scenarios where DRY principle is violated'''===

There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production. Two such tools for management control that directly violate the DRY principle are [http://en.wikipedia.org/wiki/Subversion_(software) SVN] and [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS].

This is direct violation of the DRY principle since at any given time, there could be copies of the same file in different branches allowing developers to work concurrently in different areas of the code without affection one another.

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

This violates the DRY principle by copying data locally in order to achieve faster processing than would normally be possible by having to fetch the same data across the network or another slower location.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

This example of violation of the DRY Principle allows the developers to spent less time updating documentation every time the code is changed by allowing the documentation to be directly retrieved from the source code. This is in direct violation of the DRY principle as the same data/code now appears in two different locations.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==

1. [http://en.wikipedia.org/wiki/DRY The DRY Principle]

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

=='''Further Readings'''==

1. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html applying the DRY principle to writing computer code]

2. [http://reinholdweber.com/css/refactoring-your-css-styles-to-comply-with-the-dry-principle/ Refactoring to comply with the DRY Principle]

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-23T20:15:20Z

Ncsueng: /* '''Source Version Control''' */

*This document could benefit from additional links and references that can allow the reader to go beyond the wiki material.
*I think the topic is fairly well covered, although you could provide some additional details on where else the DRY principle applies, like with certain design patterns.
*Organization could have been better.
*Coverage could have been more on the decision about when to use the principle and the desirable features of the principle.
*More examples could have been provided.

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

==='''Scenarios where DRY principle is violated'''===
There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production. Two such tools for management control that directly violate the DRY principle are [http://en.wikipedia.org/wiki/Subversion_(software) SVN] and [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS].

This is direct violation of the DRY principle since at any given time, there could be copies of the same file in different branches allowing developers to work concurrently in different areas of the code without affection one another.

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

This violates the DRY principle by copying data locally in order to achieve faster processing than would normally be possible by having to fetch the same data across the network or another slower location.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

This example of violation of the DRY Principle allows the developers to spent less time updating documentation every time the code is changed by allowing the documentation to be directly retrieved from the source code. This is in direct violation of the DRY principle as the same data/code now appears in two different locations.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==

1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

=='''Further Readings'''==

1. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html applying the DRY principle to writing computer code]

2. [http://reinholdweber.com/css/refactoring-your-css-styles-to-comply-with-the-dry-principle/ Refactoring to comply with the DRY Principle]

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-23T20:07:48Z

Ncsueng:

*This document could benefit from additional links and references that can allow the reader to go beyond the wiki material.
*I think the topic is fairly well covered, although you could provide some additional details on where else the DRY principle applies, like with certain design patterns.
*Organization could have been better.
*Coverage could have been more on the decision about when to use the principle and the desirable features of the principle.
*More examples could have been provided.

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

==='''Scenarios where DRY principle is violated'''===
There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production

This is direct violation of the DRY principle since at any given time, there could be copies of the same file in different branches, allowing developers to work concurrently in different areas of the code without affection one another.

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

This violates the DRY principle by copying data locally in order to achieve faster processing than would normally be possible by having to fetch the same data across the network or another slower location.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

This example of violation of the DRY Principle allows the developers to spent less time updating documentation every time the code is changed by allowing the documentation to be directly retrieved from the source code. This is in direct violation of the DRY principle as the same data/code now appears in two different locations.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==

1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

=='''Further Readings'''==

1. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html applying the DRY principle to writing computer code]

2. [http://reinholdweber.com/css/refactoring-your-css-styles-to-comply-with-the-dry-principle/ Refactoring to comply with the DRY Principle]

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-23T20:03:19Z

Ncsueng:

*This document could benefit from additional links and references that can allow the reader to go beyond the wiki material.
*I think the topic is fairly well covered, although you could provide some additional details on where else the DRY principle applies, like with certain design patterns.
*Organization could have been better.
*Coverage could have been more on the decision about when to use the principle and the desirable features of the principle.
*More examples could have been provided.

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

==='''Scenarios where DRY principle is violated'''===
There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production

This is direct violation of the DRY principle since at any given time, there could be copies of the same file in different branches, allowing developers to work concurrently in different areas of the code without affection one another.

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

This violates the DRY principle by copying data locally in order to achieve faster processing than would normally be possible by having to fetch the same data across the network or another slower location.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

This example of violation of the DRY Principle allows the developers to spent less time updating documentation every time the code is changed by allowing the documentation to be directly retrieved from the source code. This is in direct violation of the DRY principle as the same data/code now appears in two different locations.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==

1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

=='''Further Readings'''==

1. [http://www.stat.auckland.ac.nz/~paul/ItDT/HTML/node23.html applying the DRY principle to writing computer code]

2. http://wolfbyte-net.blogspot.com/2009/01/ccd-red-degree-principle-staying-dry.html

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-23T04:25:45Z

Ncsueng:

*sections 4-6 could are very brief but perhaps you could explain how they relate to DRY
*This document could benefit from additional links and references that can allow the reader to go beyond the wiki material.
*I think the topic is fairly well covered, although you could provide some additional details on where else the DRY principle applies, like with certain design patterns.
*Organization could have been better.
*Coverage could have been more on the decision about when to use the principle and the desirable features of the principle.
*More examples could have been provided.

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

==='''Scenarios where DRY principle is violated'''===
There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-23T04:23:17Z

Ncsueng:

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

==='''Scenarios where DRY principle is violated'''===
There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

===='''Source Version Control'''====

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production

===='''Caching'''====
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

===='''Documentation'''====
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

==='''How to determine when to duplicate data'''===

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-19T02:42:44Z

Ncsueng: /* '''DRY principle - Code''' */

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one way to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

=='''Source Version Control'''==

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production

=='''Caching'''==
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

=='''Documentation'''==
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

=='''How to determine when to duplicate data'''==

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-19T02:37:21Z

Ncsueng:

__TOC__

=='''Don't Repeat Yourself - Introduction'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed, and in general, data should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

There are certain scenarios, however, where duplication might not only be acceptable, but at times desirable. However, in order to avoid the reasons just mentioned, certain rules should be followed.

=='''Source Version Control'''==

[http://en.wikipedia.org/wiki/Version_control Source version control] is a management control tool that tracks different versions of data. It is usually used in software development teams where several people might be making change to the same file. It allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production

=='''Caching'''==
[http://en.wikipedia.org/wiki/Caching Caching] of data is the duplication of data that has been retrieved from a certain location, or calculated at an earlier time. It is used when the time or processing power would be expensive to retrieve/calculate the data again. Caching has proved to be useful in numerous applications including caching large amount of data transferred on the network, or caching data inside the processors that have been retrieved from memory.

=='''Documentation'''==
Documentation can be automatically pulled and generated from code, which would essentially duplicate code and comments to create the document. This is a useful technique since an updated documentation can be directly retrieved and created from the modified code without requiring individual to manually modify the doc. This actually ensures that the document is up-to-date based on the latest code.

=='''How to determine when to duplicate data'''==

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3] The duplication of data should only be considered when it will save time or resources or both. Furthermore, the authoritative source of the data is well known.

=='''Conclusion'''==

Ideally, code and data should not be duplicated making maintainability and synchronization of information easy. However, this document has described several scenarios where violating the DRY principle with regards to the duplication of data is acceptable. In all examples provided, duplicating data significantly saved network bandwidth, computing processing, or human time. Also, in all of the examples, only a single source of data was the authoritative source.

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-19T01:57:34Z

Ncsueng:

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-19T01:32:40Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''Don't Repeat Yourself'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed. In general, data, just like code, should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

There are certain scenarios where duplication might not only be acceptable, but at times desirable.

=='''Source Version Control'''==

In some instances, the duplication of data might actually be acceptable and even desirable.

* Source version control allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production

=='''Caching'''==
* Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency as long as the authoritative source is well known.

=='''Documentation'''==
* Documentation can be automatically generated from code, which would essentially duplicate code and comments to create the document.

=='''Data duplication - when is it useful?'''==

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3]

=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-19T01:28:49Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''Don't Repeat Yourself'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

=='''DRY principle - Code'''==

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

=='''DRY principle - Data'''==

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed. In general, data, just like code, should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

=='''Data duplication - acceptable?'''==

In some instances, the duplication of data might actually be acceptable and even desirable.

* Source version control allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production
* Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency as long as the authoritative source is well known.
* Documentation can be automatically generated from code, which would essentially duplicate code and comments to create the document.

=='''Data duplication - when is it useful?'''==

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3]

=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-19T01:27:06Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''Don't Repeat Yourself'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the rest of the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

==='''DRY principle - Code'''===

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

==='''DRY principle - Data'''===

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed. In general, data, just like code, should not be duplicated for the following reasons:

* Additional memory - data duplication usually means more memory to store and manipulate
* Out-of-date Data - data duplication usually means that you need to keep the same data in multiple locations in sync

===='''Data duplication - acceptable?'''====

In some instances, the duplication of data might actually be acceptable and even desirable.

* Source version control allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production
* Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency as long as the authoritative source is well known.
* Documentation can be automatically generated from code, which would essentially duplicate code and comments to create the document.

===='''Data duplication - when is it useful?'''====

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3]

=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-18T04:17:35Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''Don't Repeat Yourself'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

==='''DRY principle - Code'''===

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

==='''DRY principle - Data'''===

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed. In general, data, just like code, should not be duplicated as a change in one location would leave the data out of sync with somewhere else.

===='''Data duplication - acceptable?'''====

In some instances, the duplication of data might actually be acceptable and even desirable.

* Source version control allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production
* Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency as long as the authoritative source is well known.
* Documentation can be automatically generated from code, which would essentially duplicate code and comments to create the document.

===='''Data duplication - when is it useful?'''====

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3]

=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-18T04:16:40Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''Don't Repeat Yourself'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

==='''DRY principle - Code'''===

The idea of why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Repeated Code
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': DRY Principle
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

==='''DRY principle - Data'''===

Most of the documentation regarding the DRY principle usually discusses the duplication of code in methods and functions in a system, but the principle also applies to data. Data can be created, passed around, copied and destroyed. In general, data, just like code, should not be duplicated as a change in one location would leave the data out of sync with somewhere else.

===='''Data duplication'''====

In some instances, the duplication of data might actually be acceptable and even desirable.

* Source version control allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production
* Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency as long as the authoritative source is well known.
* Documentation can be automatically generated from code, which would essentially duplicate code and comments to create the document.

===='''How to decide when data duplication might be useful'''====

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3]

=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-18T03:41:50Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''Don't Repeat Yourself'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

==='''DRY principle - Code'''===

The idea why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Java classes repeat functionality
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': Java classes with repeated functionality factored out
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to other classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

==='''DRY principle - Data'''===

The DRY principle not only applies to methods and functions in a system, but also to data. Data can be created, passed around, copied and destroyed. In general, data, just like code, should not be duplicated as a change in one location would leave the data out of sync with somewhere else.

===='''When data duplication might be acceptable'''====

In some instances, the duplication of data might actually be acceptable and even desirable.

* Source version control allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production
* Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency as long as the authoritative source is well known.
* Documentation can be automatically generated from code, which would essentially duplicate code and comments to create the document.

===='''How to decide when data duplication might be useful'''====

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3]

=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

4.

5.

6.

7.

8.

9.

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-12T23:43:24Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''An overview of the concepts'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

==='''Don't Repeat Yourself'''===

[[Image:DRY.jpg]]

==='''DRY principle - Code'''===

The idea why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Java classes repeat functionality
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': Java classes with repeated functionality factored out
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to other classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

==='''DRY principle - Data'''===

The DRY principle not only applies to methods and functions in a system, but also to data. Data can be created, passed around, copied and destroyed. In general, data, just like code, should not be duplicated as a change in one location would leave the data out of sync with somewhere else.

===='''When data duplication might be acceptable'''====

In some instances, the duplication of data might actually be acceptable and even desirable.

* Source version control allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production
* Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency as long as the authoritative source is well known.
* Documentation can be automatically generated from code, which would essentially duplicate code and comments to create the document.

===='''How to decide when data duplication might be useful'''====

When considering whether data duplication might be helpful and acceptable, one must "identify the single, definitive source of every piece of knowledge used in your system, and then use that source to generate applicable instances of that knowledge (code, documentation, tests, etc)." [3]

=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

4.

5.

6.

7.

8.

9.

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-12T23:31:34Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''An overview of the concepts'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

==='''Don't Repeat Yourself'''===

[[Image:DRY.jpg]]

==='''DRY principle - Code'''===

The idea why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Java classes repeat functionality
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': Java classes with repeated functionality factored out
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to other classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

==='''DRY principle - Data'''===

The DRY principle not only applies to methods and functions in a system, but also to data. Data can be created, passed around, copied and destroyed. In general, data, just like code, should not be duplicated as a change in one location would leave the data out of sync with somewhere else.

===='''When data duplication might be acceptable'''====

In some instances, the duplication of data might actually be acceptable and even desirable.

* Source version control allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production
* Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency as long as the authoritative source is well known.

===='''How to decide when data duplication might be useful'''====

=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3. http://c2.com/cgi/wiki?DontRepeatYourself

4.

5.

6.

7.

8.

9.

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-12T23:07:39Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''An overview of the concepts'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

==='''Don't Repeat Yourself'''===

[[Image:DRY.jpg]]

==='''DRY principle - Code'''===

The idea why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Java classes repeat functionality
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': Java classes with repeated functionality factored out
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to other classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

==='''DRY principle - Data'''===

The DRY principle not only applies to methods and functions in a system, but also to data. Data can be created, passed around, copied and destroyed. In general, data, just like code, should not be duplicated as a change in one location would leave the data out of sync with somewhere else.

===='''When data duplication might be acceptable'''====

In some instances, the duplication of data might actually be acceptable and even desirable.

* Source version control allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production
* Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency, however, the original source of data has to be known, and some type of information should be validated to decide that the cached data is still valid.

=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3.

4.

5.

6.

7.

8.

9.

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-12T23:07:16Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''An overview of the concepts'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) does not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave code (or functionality) somewhere else unmodified and out of sync.

==='''Don't Repeat Yourself'''===

[[Image:DRY.jpg]]

==='''DRY principle - Code'''===

The idea why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Java classes repeat functionality
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': Java classes with repeated functionality factored out
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to other classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

==='''DRY principle - Data'''===

The DRY principle not only applies to methods and functions in a system, but also to data. Data can be created, passed around, copied and destroyed. In general, data, just like code, should not be duplicated as a change in one location would leave the data out of sync with somewhere else.

===='''When data duplication might be acceptable'''====

In some instances, the duplication of data might actually be acceptable and even desirable.

* Source version control allows multiple copies of the data, sometimes with slight variations, in different branches and tags. This is a good practice for this tool since at any given time there could be code in several stages: development, testing and production
* Caching of data can also prove to be useful if directly obtaining the data each time is resource and time intensive. Caching data would result in better system efficiency, however, the original source of data has to be known, and some type of information should be validated to decide that the cached data is still valid.

=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3.

4.

5.

6.

7.

8.

9.

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-10T01:54:06Z

Ncsueng:

Topic: DRY principle for data
Most of the literature on the DRY principle relates to code. But the principle also applies to data. Survey the issues related to copying the same data, and give reasons (e.g., caching) why it might sometimes be desirable, and how one should decide where it is helpful not to follow this general rule.

__TOC__

=='''An overview of the concepts'''==

[http://en.wikipedia.org/wiki/DRY ''DRY''] (or Don't Repeat Yourself) is a software engineering principle that says that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system" [1]. By applying DRY practice to your software, the system is broken down into smaller parts with logically unrelated pieces separated, allowing easier changes to one element without affecting the system. DRY also helps by keeping related code together, and making sure that the same code (or even just the same functionality) do not appear in two different locations in the system. This helps with ensuring that fixing one bug, or enhancing one part of the system, does not leave the same code (or functionality) somewhere else unmodified.

==='''Don't Repeat Yourself'''===

[[Image:DRY.jpg]]

==='''DRY principle - related to code'''===

The idea why one does not want more than one way to represent something in the system is simple: if you have more than one to represent something, with time, the different representation are more likely to be out of sync. As Dave Thomas, author of Programming Ruby: A Pragmatic Programmer's Guide, says "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." [2]

:*'''''Example''': Java classes repeat functionality
public class Student {
private String name;
private String address;
private String gpa;
public String getName() { return name; }
public String getAddress() { return address; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private String name;
private String address;
private String salary;
public String getName() { return name; }
public String getAddress() { return address; }
public String getSalary() { return salary; }
... other methods and data ...
}

:*'''''Example''': Java classes with repeated functionality factored out
public class Person {
private String name;
private String address;
public String getName() { return name; }
public String getAddress() { return address; }
}
public class Student {
private Person me;
private String gpa;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getGPA() { return gpa; }
... other methods and data ...
}
public class Employee {
private Person me;
private String salary;
public String getName() { return me.getName; }
public String getAddress() { return me.getAddress; }
public String getSalary() { return salary; }
... other methods and data ...
}

The example above can be applied to other classes where the common code does not only return a string, but instead performs some kind of procedure or calculation. In such a scenario, if the programmer was to make a change to one of the procedure and was not aware of the other, the code now would be different, possibly even providing different results.

==='''DRY principle - related to data'''===

The DRY principle not only applies to methods and functions, but also to data.

===='''DRY principle - bad when used with data'''====
===='''DRY principle - good when used with data'''====
=='''Conclusion'''==

=='''References'''==
'''
1. http://en.wikipedia.org/wiki/DRY

2. [http://www.artima.com/intv/dry.html Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II]

3.

4.

5.

6.

7.

8.

9.

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-10T01:26:59Z

Ncsueng:

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-10T01:24:51Z

Ncsueng:

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-10T00:01:15Z

Ncsueng:

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-09T01:58:17Z

Ncsueng:

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-09T01:26:02Z

Ncsueng:

CSC/ECE 517 Fall 2009/wiki3 4 br

2009-11-09T01:17:15Z

Ncsueng:

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-14T01:11:45Z

Ncsueng: /* '''Metaprogramming''' */

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated, specifically how reflection and metaprogramming support SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. The SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages. [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain data, sufficient detail about the characteristic of the data and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. Furthermore, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA does not limit the protocol used to transfer the data. A wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

:*'''''Example''': Metaprogramming in Ruby [http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox 9]
Array.send(:define_method, :ducky) { puts 'ducky' }

This example does something particularly interesting. At run time, it defines a new method called ducky that prints out the word "ducky". This line modifies the program at run time!

Another example in Ruby is the ActiveRecord library. It dynamically creates accessor methods that map directly to each column in the database.

:*'''''Example''': ActiveRecord metaprogramming in Ruby [10]
class Movie < ActiveRecord::Base
end

movie = Movie.create
movie.title = "Doctor Strangelove"
movie.title # => "Doctor Strangelove"

In the example above, we create a new instance of Movie, which subclasses ActiveRecord. We then directly access the database's title column using the setter method 'title=' and then the getter method 'title'. These methods are not defined anywhere in the source code, but instead, ActiveRecord automatically defines them based on the database column.

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

:*'''''Example''': Reflection in Ruby [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]

# without reflection
Foo.new.hello

# with reflection
Object.const_get(:Foo).new.send(:hello)

In this example, the first and second lines illustrate how the code is written without reflection. The first line is a comment, and the second line is the actual code. The code calls on Foo.new.hello, which calls on the object Foo, method new, and from what is returned on that, calls the method hello. The second section does practically the same thing, but with reflection. The main difference is that the object called by :hello can be determined at run time.

:*'''''Example''': More Reflection in Ruby [http://www.ruby-doc.org/core/classes/ObjectSpace.html 8]

ObjectSpace.each_object(Numeric) {|x| p x }

In this example, Ruby can determine all the objects that are defined. This particular line of code prints out all the numeric objects that are currently defined.

=='''How metaprogramming and reflection enhance SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' in a language independent way, the receiving service would use metaprogramming to write code to just that. The service would then use reflection to determine what methods are available, in our case 'print', and would perform that task. If the service logic was to "repeat 3 times", then the code would ultimately print "Hello World" that number of times.

XML may be used to transfer the message as follows:

:*'''''Example''' XML Data:

<message>
<method>print</method>
<data>Hello World</data>
</message>

A more practical use of reflection and metaprogramming in a SOA would be a service that examines the code passed to it for security holes. This service could use reflection to examine the code. The code could be sent to the service via whatever protocol is chosen. Next, the service would evaluate the code for common security flaws. If the program is determined to be safe enough, the service may run the code in a safe environment and perform further testing. The service would output the results of the analysis, and perhaps even an auto-corrected program when it is complete.

Currently, compilers are a good illustration of metaprogramming and reflection working in a service. The compiler may be viewed as a service within SOA's. It can be run on many different systems, which is a major benefit of SOA's. Data (the code) is sent to a service (the compiler) which then translates it to machine code for the particular system. Metaprogramming is at work here, because each line of code is generally used to write one or more lines of machine code. The code and compiler effectively write a new program in machine code. Machine code is code that a system can execute. Reflection may take place when symbols generated by one section of code are referenced by another section of code. [http://dvanderboom.wordpress.com/2008/11/06/programming-language-directions/ 11]

A pattern emerges when studying these examples. Metaprogramming and reflection may be used within the service to enhance the capability of the service. The data passed in to the service is often what guides how metaprogramming and reflection take place.

=='''Conclusion'''==

SOA is an evolution of distributed computing based on web services. It is an attractive solution for companies since it is platform independent allowing different software and hardware to communicate together easily.

Metaprogramming and reflection are programming styles used to take advantage of the features in dynamic programming languages. They provide a great advantage when used in the development of SOAs to allow the services to dynamically change and adapt to the messages being passed between services.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

8. http://www.ruby-doc.org/core/classes/ObjectSpace.html - Explanation of the ObjectSpace command in Ruby

9. http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox - Explanation of tools that Ruby provides for metaprogramming

10. Perrotta, Paolo (2009). ''Metaprogramming Ruby''.

11. http://dvanderboom.wordpress.com/2008/11/06/programming-language-directions/ - Illustrates the use of a compiler as a service

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-13T03:46:57Z

Ncsueng: /* '''References''' */

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated, specifically how reflection and metaprogramming support SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages. [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA does not limit the protocol used to transfer the data. A wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

:*'''''Example''': Metaprogramming in Ruby [http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox 9]
Array.send(:define_method, :ducky) { puts 'ducky' }

This example does something particularly interesting. At run time, it defines a new method called ducky that prints out the word "ducky". This line modifies the program at run time!

Another example in Ruby is the ActiveRecord library. It dynamically creates accessor methods that map directly to each column in the database.

:*'''''Example''': ActiveRecord metaprogramming in Ruby [10]
class Movie < ActiveRecord::Base
end

movie = Movie.create
movie.title = "Doctor Strangelove"
movie.title # => "Doctor Strangelove"

In the example above, we create a new instance of Movie, which subclasses ActiveRecord::Base, and then call the setter method 'title=', and then the getter method 'title'. Neither of these methods is defined anywhere in the source code, but instead, ActiveRecord automatically defines them.

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

:*'''''Example''': Reflection in Ruby [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]

# without reflection
Foo.new.hello

# with reflection
Object.const_get(:Foo).new.send(:hello)

In this example, the first and second lines illustrate how the code is written without reflection. The first line is a comment, and the second line is the actual code. The code calls on Foo.new.hello, which calls on the object Foo, method new, and from what is returned on that, calls the method hello. The second section does practically the same thing, but with reflection. The main difference is that the object called by :hello can be determined at run time.

:*'''''Example''': More Reflection in Ruby [http://www.ruby-doc.org/core/classes/ObjectSpace.html 8]

ObjectSpace.each_object(Numeric) {|x| p x }

In this example, Ruby can determine all the objects that are defined. This particular line of code prints out all the numeric objects that are currently defined.

=='''How metaprogramming and reflection enhance SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' in a language independent way, the receiving service would use metaprogramming to write code to just that. The service would then use reflection to determine what methods are available, in our case 'print', and would perform that task. If the service logic was to "repeat 3 times", then the code would ultimately print "Hello World" that number of times.

XML may be used to transfer the message as follows:

:*'''''Example''' XML Data:

<message>
<method>print</method>
<data>Hello World</data>
</message>

A more practical use of reflection and metaprogramming in a SOA would be a service that examines the code passed to it for security holes. This service could use reflection to examine the code. The code could be sent to the service via whatever protocol is chosen. Next, the service would evaluate the code for common security flaws. If the program is determined to be safe enough, the service may run the code in a safe environment and perform further testing. The service would output the results of the analysis, and perhaps even an auto-corrected program when it is complete.

=='''Conclusion'''==

SOA is an evolution of distributed computing based on web services. It is an attractive solution for companies since it is platform independent allowing different software and hardware to communicate together easily.

Metaprogramming and reflection are programming styles used to take advantage of the features in dynamic programming languages. They provide a great advantage when used in the development of SOAs to allow the services to dynamically change and adapt to the messages being passed between services.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

8. http://www.ruby-doc.org/core/classes/ObjectSpace.html - Explanation of the ObjectSpace command in Ruby

9. http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox - Explanation of tools that Ruby provides for metaprogramming

10. Perrotta, Paolo (2009). ''Metaprogramming Ruby''.

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-13T03:45:59Z

Ncsueng: /* '''Metaprogramming''' */

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated, specifically how reflection and metaprogramming support SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages. [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA does not limit the protocol used to transfer the data. A wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

:*'''''Example''': Metaprogramming in Ruby [http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox 9]
Array.send(:define_method, :ducky) { puts 'ducky' }

This example does something particularly interesting. At run time, it defines a new method called ducky that prints out the word "ducky". This line modifies the program at run time!

Another example in Ruby is the ActiveRecord library. It dynamically creates accessor methods that map directly to each column in the database.

:*'''''Example''': ActiveRecord metaprogramming in Ruby [10]
class Movie < ActiveRecord::Base
end

movie = Movie.create
movie.title = "Doctor Strangelove"
movie.title # => "Doctor Strangelove"

In the example above, we create a new instance of Movie, which subclasses ActiveRecord::Base, and then call the setter method 'title=', and then the getter method 'title'. Neither of these methods is defined anywhere in the source code, but instead, ActiveRecord automatically defines them.

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

:*'''''Example''': Reflection in Ruby [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]

# without reflection
Foo.new.hello

# with reflection
Object.const_get(:Foo).new.send(:hello)

In this example, the first and second lines illustrate how the code is written without reflection. The first line is a comment, and the second line is the actual code. The code calls on Foo.new.hello, which calls on the object Foo, method new, and from what is returned on that, calls the method hello. The second section does practically the same thing, but with reflection. The main difference is that the object called by :hello can be determined at run time.

:*'''''Example''': More Reflection in Ruby [http://www.ruby-doc.org/core/classes/ObjectSpace.html 8]

ObjectSpace.each_object(Numeric) {|x| p x }

In this example, Ruby can determine all the objects that are defined. This particular line of code prints out all the numeric objects that are currently defined.

=='''How metaprogramming and reflection enhance SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' in a language independent way, the receiving service would use metaprogramming to write code to just that. The service would then use reflection to determine what methods are available, in our case 'print', and would perform that task. If the service logic was to "repeat 3 times", then the code would ultimately print "Hello World" that number of times.

XML may be used to transfer the message as follows:

:*'''''Example''' XML Data:

<message>
<method>print</method>
<data>Hello World</data>
</message>

A more practical use of reflection and metaprogramming in a SOA would be a service that examines the code passed to it for security holes. This service could use reflection to examine the code. The code could be sent to the service via whatever protocol is chosen. Next, the service would evaluate the code for common security flaws. If the program is determined to be safe enough, the service may run the code in a safe environment and perform further testing. The service would output the results of the analysis, and perhaps even an auto-corrected program when it is complete.

=='''Conclusion'''==

SOA is an evolution of distributed computing based on web services. It is an attractive solution for companies since it is platform independent allowing different software and hardware to communicate together easily.

Metaprogramming and reflection are programming styles used to take advantage of the features in dynamic programming languages. They provide a great advantage when used in the development of SOAs to allow the services to dynamically change and adapt to the messages being passed between services.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

8. http://www.ruby-doc.org/core/classes/ObjectSpace.html - Explanation of the ObjectSpace command in Ruby

9. http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox - Explanation of tools that Ruby provides for metaprogramming

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-13T03:45:27Z

Ncsueng: /* '''Metaprogramming''' */

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated, specifically how reflection and metaprogramming support SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages. [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA does not limit the protocol used to transfer the data. A wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

:*'''''Example''': Metaprogramming in Ruby [http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox 9]
Array.send(:define_method, :ducky) { puts 'ducky' }

This example does something particularly interesting. At run time, it defines a new method called ducky that prints out the word "ducky". This line modifies the program at run time!

Another example in Ruby is the ActiveRecord library. It dynamically creates accessor methods that map directly to each column in the database.

:*'''''Example''': ActiveRecord metaprogramming in Ruby
class Movie < ActiveRecord::Base
end

movie = Movie.create
movie.title = "Doctor Strangelove"
movie.title # => "Doctor Strangelove"

In the example above, we create a new instance of Movie, which subclasses ActiveRecord::Base, and then call the setter method 'title=', and then the getter method 'title'. Neither of these methods is defined anywhere in the source code, but instead, ActiveRecord automatically defines them.

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

:*'''''Example''': Reflection in Ruby [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]

# without reflection
Foo.new.hello

# with reflection
Object.const_get(:Foo).new.send(:hello)

In this example, the first and second lines illustrate how the code is written without reflection. The first line is a comment, and the second line is the actual code. The code calls on Foo.new.hello, which calls on the object Foo, method new, and from what is returned on that, calls the method hello. The second section does practically the same thing, but with reflection. The main difference is that the object called by :hello can be determined at run time.

:*'''''Example''': More Reflection in Ruby [http://www.ruby-doc.org/core/classes/ObjectSpace.html 8]

ObjectSpace.each_object(Numeric) {|x| p x }

In this example, Ruby can determine all the objects that are defined. This particular line of code prints out all the numeric objects that are currently defined.

=='''How metaprogramming and reflection enhance SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' in a language independent way, the receiving service would use metaprogramming to write code to just that. The service would then use reflection to determine what methods are available, in our case 'print', and would perform that task. If the service logic was to "repeat 3 times", then the code would ultimately print "Hello World" that number of times.

XML may be used to transfer the message as follows:

:*'''''Example''' XML Data:

<message>
<method>print</method>
<data>Hello World</data>
</message>

A more practical use of reflection and metaprogramming in a SOA would be a service that examines the code passed to it for security holes. This service could use reflection to examine the code. The code could be sent to the service via whatever protocol is chosen. Next, the service would evaluate the code for common security flaws. If the program is determined to be safe enough, the service may run the code in a safe environment and perform further testing. The service would output the results of the analysis, and perhaps even an auto-corrected program when it is complete.

=='''Conclusion'''==

SOA is an evolution of distributed computing based on web services. It is an attractive solution for companies since it is platform independent allowing different software and hardware to communicate together easily.

Metaprogramming and reflection are programming styles used to take advantage of the features in dynamic programming languages. They provide a great advantage when used in the development of SOAs to allow the services to dynamically change and adapt to the messages being passed between services.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

8. http://www.ruby-doc.org/core/classes/ObjectSpace.html - Explanation of the ObjectSpace command in Ruby

9. http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox - Explanation of tools that Ruby provides for metaprogramming

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-13T03:30:21Z

Ncsueng: /* '''How metaprogramming and reflection enhance SOA''' */

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated, specifically how reflection and metaprogramming support SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages. [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA does not limit the protocol used to transfer the data. A wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

:*'''''Example''': Metaprogramming in Ruby [http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox 9]
Array.send(:define_method, :ducky) { puts 'ducky' }

This example does something particularly interesting. At run time, it defines a new method called ducky that prints out the word "ducky". This line modifies the program at run time!

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

:*'''''Example''': Reflection in Ruby [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]

# without reflection
Foo.new.hello

# with reflection
Object.const_get(:Foo).new.send(:hello)

In this example, the first and second lines illustrate how the code is written without reflection. The first line is a comment, and the second line is the actual code. The code calls on Foo.new.hello, which calls on the object Foo, method new, and from what is returned on that, calls the method hello. The second section does practically the same thing, but with reflection. The main difference is that the object called by :hello can be determined at run time.

:*'''''Example''': More Reflection in Ruby [http://www.ruby-doc.org/core/classes/ObjectSpace.html 8]

ObjectSpace.each_object(Numeric) {|x| p x }

In this example, Ruby can determine all the objects that are defined. This particular line of code prints out all the numeric objects that are currently defined.

=='''How metaprogramming and reflection enhance SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' in a language independent way, the receiving service would use metaprogramming to write code to just that. The service would then use reflection to determine what methods are available, in our case 'print', and would perform that task. If the service logic was to "repeat 3 times", then the code would ultimately print "Hello World" that number of times.

XML may be used to transfer the message as follows:

:*'''''Example''' XML Data:

<message>
<method>print</method>
<data>Hello World</data>
</message>

A more practical use of reflection and metaprogramming in a SOA would be a service that examines the code passed to it for security holes. This service could use reflection to examine the code. The code could be sent to the service via whatever protocol is chosen. Next, the service would evaluate the code for common security flaws. If the program is determined to be safe enough, the service may run the code in a safe environment and perform further testing. The service would output the results of the analysis, and perhaps even an auto-corrected program when it is complete.

=='''Conclusion'''==

SOA is an evolution of distributed computing based on web services. It is an attractive solution for companies since it is platform independent allowing different software and hardware to communicate together easily.

Metaprogramming and reflection are programming styles used to take advantage of the features in dynamic programming languages. They provide a great advantage when used in the development of SOAs to allow the services to dynamically change and adapt to the messages being passed between services.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

8. http://www.ruby-doc.org/core/classes/ObjectSpace.html - Explanation of the ObjectSpace command in Ruby

9. http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox - Explanation of tools that Ruby provides for metaprogramming

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-13T03:29:26Z

Ncsueng: /* '''How metaprogramming and reflection enhance SOA''' */

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated, specifically how reflection and metaprogramming support SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages. [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA does not limit the protocol used to transfer the data. A wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

:*'''''Example''': Metaprogramming in Ruby [http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox 9]
Array.send(:define_method, :ducky) { puts 'ducky' }

This example does something particularly interesting. At run time, it defines a new method called ducky that prints out the word "ducky". This line modifies the program at run time!

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

:*'''''Example''': Reflection in Ruby [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]

# without reflection
Foo.new.hello

# with reflection
Object.const_get(:Foo).new.send(:hello)

In this example, the first and second lines illustrate how the code is written without reflection. The first line is a comment, and the second line is the actual code. The code calls on Foo.new.hello, which calls on the object Foo, method new, and from what is returned on that, calls the method hello. The second section does practically the same thing, but with reflection. The main difference is that the object called by :hello can be determined at run time.

:*'''''Example''': More Reflection in Ruby [http://www.ruby-doc.org/core/classes/ObjectSpace.html 8]

ObjectSpace.each_object(Numeric) {|x| p x }

In this example, Ruby can determine all the objects that are defined. This particular line of code prints out all the numeric objects that are currently defined.

=='''How metaprogramming and reflection enhance SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' in a language independent way, the receiving service would use metaprogramming to write code to just that. The service would then use reflection to determine was is available, in our case 'print', and would perform that task. If the service logic was to "repeat 3 times", then the code would ultimately print "Hello World" that number of times.

XML may be used to transfer the message as follows:

:*'''''Example''' XML Data:

<message>
<method>print</method>
<data>Hello World</data>
</message>

A more practical use of reflection and metaprogramming in a SOA would be a service that examines the code passed to it for security holes. This service could use reflection to examine the code. The code could be sent to the service via whatever protocol is chosen. Next, the service would evaluate the code for common security flaws. If the program is determined to be safe enough, the service may run the code in a safe environment and perform further testing. The service would output the results of the analysis, and perhaps even an auto-corrected program when it is complete.

=='''Conclusion'''==

SOA is an evolution of distributed computing based on web services. It is an attractive solution for companies since it is platform independent allowing different software and hardware to communicate together easily.

Metaprogramming and reflection are programming styles used to take advantage of the features in dynamic programming languages. They provide a great advantage when used in the development of SOAs to allow the services to dynamically change and adapt to the messages being passed between services.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

8. http://www.ruby-doc.org/core/classes/ObjectSpace.html - Explanation of the ObjectSpace command in Ruby

9. http://weare.buildingsky.net/2009/08/25/rubys-metaprogramming-toolbox - Explanation of tools that Ruby provides for metaprogramming

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-13T02:53:35Z

Ncsueng:

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated, specifically how reflection and metaprogramming support SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

!!!!
- Enhance final section

- Add a Conclusion

- Metaprogramming and Reflection sections were very brief. Perhaps, you could add some Ruby code instead of Python. Maybe touch on things like ObjectSpace.each_object and similar.

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages. [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA does not limit the protocol used to transfer the data. A wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes on dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

:*'''''Example''': Reflection in Ruby [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]

# without reflection
Foo.new.hello

# with reflection
Object.const_get(:Foo).new.send(:hello)

In this example, the first and second lines illustrate how the code is written without reflection. The first line is a comment, and the second line is the actual code. The code calls on Foo.new.hello, which calls on the object Foo, method new, and from what is returned on that, calls the method hello. The second section does practically the same thing, but with reflection. The main difference is that the object called by :hello can be determined at run time.

=='''How metaprogramming and reflection enhance SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' in a language independent way, the receiving service would use metaprogramming to write code to just that. The service would then use reflection to determine was is available, in our case 'print', and would perform that task. If the service logic was to "repeat 3 times", then the code would ultimately print "Hello World" that number of times.

XML may be used to transfer the message as follows:

:*'''''Example''' XML Metaprogramming:

<message>
<method>print</method>
<data>Hello World</data>
</message>

A more practical use of reflection and metaprogramming in a SOA would be a service that examines the code passed to it for security holes. This service could use reflection to examine the code. The code could be sent to the service via whatever protocol is chosen. Next, the service would evaluate the code for common security flaws. If the program is determined to be safe enough, the service may run the code in a safe environment and perform further testing. The service would output the results of the analysis, and perhaps even an auto-corrected program when it is complete.

=='''Conclusion'''==

SOA is an evolution of distributed computing based on web services. It is an attractive solution for companies since it is platform independent allowing different software and hardware to communicate together easily.

Metaprogramming and reflection are programming styles used to take advantage of the features in dynamic programming languages. They provide a great advantage when used in the development of SOAs to allow the services to dynamically change and adapt to the messages being passed between services.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-10T01:59:34Z

Ncsueng: /* '''How metaprogramming and reflection enhance SOA''' */

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-10T01:46:12Z

Ncsueng: /* '''How metaprogramming and reflection enhance SOA''' */

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-10T01:12:02Z

Ncsueng: /* '''How it is all related and enhances SOA''' */

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following three goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated.
#Examines how reflection and metaprogramming supports SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA also does not limit the protocol used to transfer the data and a wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes on dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

=='''How it is all related and enhances SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' in a language independent way, the receiving service would use metaprogramming to write code to just that. The service would then use reflection to determine was is available, in our case 'print', and would perform that task. If the service logic was to "repeat 3 times", then the code would ultimately print "Hello World" that number of times.

The application would pass the line saying to print "Hello World" to the service, would then print Hello World three times. Another more practical example would be a service that examines the code passed to it for security holes. These examples both make use of metaprogramming and reflection. One limitation to this concept, however, is that it would limit the code to a specific language. For example, if a Ruby line: puts "Hello World" is passed into a service written to accept Java code, it will not work properly. Services and applications would need to talk in the same language in this case, which would, for these applications, take away the benefit that services may be written in different languages.

A second thought we came up with is to send data that reperesents code. For example, we could pass a message that says print Hello World, and then the service would do that in whatever language it is written in. The first word could be read, and then the service could call the proper code within itself to meet that request. This could be accomplished with metaprogramming and reflection. The message could be analyzed and the method called could be changed based on what function is requested in the message.

The concept of reflection and metaprogramming can be used to extend the services and dynamically modify their behavior.

Example:
An XML metadata schema is extended to include a new tag/value. This data is now passed around between services, and each service can be extended dynamically to use it.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-10T00:56:14Z

Ncsueng: /* '''How it is all related and enhances SOA''' */

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following three goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated.
#Examines how reflection and metaprogramming supports SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA also does not limit the protocol used to transfer the data and a wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes on dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

=='''How it is all related and enhances SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"', and is language independent, the receiving service One thought we came with on how metaprogramming and reflection could be useful in a SOA is if the protocol consists of passing code. For example, a service could "repeat 3 times" and the code passed to it could print "Hello World". The application would pass the line saying to print "Hello World" to the service, would then print Hello World three times. Another more practical example would be a service that examines the code passed to it for security holes. These examples both make use of metaprogramming and reflection. One limitation to this concept, however, is that it would limit the code to a specific language. For example, if a Ruby line: puts "Hello World" is passed into a service written to accept Java code, it will not work properly. Services and applications would need to talk in the same language in this case, which would, for these applications, take away the benefit that services may be written in different languages.

A second thought we came up with is to send data that reperesents code. For example, we could pass a message that says print Hello World, and then the service would do that in whatever language it is written in. The first word could be read, and then the service could call the proper code within itself to meet that request. This could be accomplished with metaprogramming and reflection. The message could be analyzed and the method called could be changed based on what function is requested in the message.

The concept of reflection and metaprogramming can be used to extend the services and dynamically modify their behavior.

Example:
An XML metadata schema is extended to include a new tag/value. This data is now passed around between services, and each service can be extended dynamically to use it.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-10T00:52:05Z

Ncsueng:

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following three goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated.
#Examines how reflection and metaprogramming supports SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA also does not limit the protocol used to transfer the data and a wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes on dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

=='''How it is all related and enhances SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

The services in a Service-oriented Architecture make use of the data passed around between them. If the data passed around represents code, One thought we came with on how metaprogramming and reflection could be useful in a SOA is if the protocol consists of passing code. For example, a service could "repeat 3 times" and the code passed to it could print "Hello World". The application would pass the line saying to print "Hello World" to the service, would then print Hello World three times. Another more practical example would be a service that examines the code passed to it for security holes. These examples both make use of metaprogramming and reflection. One limitation to this concept, however, is that it would limit the code to a specific language. For example, if a Ruby line: puts "Hello World" is passed into a service written to accept Java code, it will not work properly. Services and applications would need to talk in the same language in this case, which would, for these applications, take away the benefit that services may be written in different languages.

A second thought we came up with is to send data that reperesents code. For example, we could pass a message that says print Hello World, and then the service would do that in whatever language it is written in. The first word could be read, and then the service could call the proper code within itself to meet that request. This could be accomplished with metaprogramming and reflection. The message could be analyzed and the method called could be changed based on what function is requested in the message.

The concept of reflection and metaprogramming can be used to extend the services and dynamically modify their behavior.

Example:
An XML metadata schema is extended to include a new tag/value. This data is now passed around between services, and each service can be extended dynamically to use it.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-10T00:46:09Z

Ncsueng: /* '''An overview of the concepts''' */

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following three goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated.
#Examines how reflection and metaprogramming supports SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architecture'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished by passing messages [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

SOA offers the following technical advantages:
*Offers services across platforms
*Allows services to be split across systems and networks
*Allows services to be location independent and close to their business units
*Provides a bridge between incompatible technologies
*Leverages existing technologies
*Reduces dependency on custom systems

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, [http://en.wikipedia.org/wiki/Metadata Metadata] (data that describes the actual data) [http://en.wikipedia.org/wiki/Metadata 6] in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.

SOA also does not limit the protocol used to transfer the data and a wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

[[Image:SOA_Example.jpg]]

We created this simplified image to illustrate the basic principles of service oriented architectures.
* Services may be used by multiple applications.
* Services do not call on each other.
* Services communicate via protocols.
* An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
* Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. [http://en.wikipedia.org/wiki/Metaprogramming 7]

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes on dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

=='''How it is all related'''==

=='''Enhancing SOA'''==

Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.

For example, a SOA system might have services located in entirely different locations, maintained by different teams of programmers and written in different programming languages. A modification to the system could potentially require the different teams, who might be in different physical locations, to coordinate the development and deployment of this enhancement. This task could turn out to be extremelly difficult to complete, making the process longer and more costly. It would then be more difficult to justify any change.
!!!! How does metaprogramming and reflection address this?

One thought we came with on how metaprogramming and reflection could be useful in a SOA is if the protocol consists of passing code. For example, a service could "repeat 3 times" and the code passed to it could print "Hello World". The application would pass the line saying to print "Hello World" to the service, would then print Hello World three times. Another more practical example would be a service that examines the code passed to it for security holes. These examples both make use of metaprogramming and reflection. One limitation to this concept, however, is that it would limit the code to a specific language. For example, if a Ruby line: puts "Hello World" is passed into a service written to accept Java code, it will not work properly. Services and applications would need to talk in the same language in this case, which would, for these applications, take away the benefit that services may be written in different languages.

A second thought we came up with is to send data that reperesents code. For example, we could pass a message that says print Hello World, and then the service would do that in whatever language it is written in. The first word could be read, and then the service could call the proper code within itself to meet that request. This could be accomplished with metaprogramming and reflection. The message could be analyzed and the method called could be changed based on what function is requested in the message.

The concept of reflection and metaprogramming can be used to extend the services and dynamically modify their behavior.

Example:
An XML metadata schema is extended to include a new tag/value. This data is now passed around between services, and each service can be extended dynamically to use it.

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection

6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata

7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-09T23:44:16Z

Ncsueng:

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-09T01:07:48Z

Ncsueng:

!!!! I have copied things that help with formatting the page from my prior wiki. Feel free to add in anything that you think may help with formatting from your project.

!!!! Main topic (to keep us on track):

!!!! Note: Delete all the !!!! parts when done. These are notes while developing the wiki.

!!!! SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. To provide services, platforms rely upon principles and the power that can be expressed through reflection and meta programming. Research and report how these critical concepts relate to and support SOA.

!!!! Reword the following paragraph to "sound better".D: I am not sure if it sounds better, but here's my first pass at it. I'm not sure what verb should go in place of 'solve'

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article describes how this is possible and '''solves??''' three goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated.
#Examines how reflection and metaprogramming supports SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architectures'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished with by passing messages [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

!!!! If we can, find a way to make the footnote in brackets, without brackets will probably work though.
!!!! Did you intend to say "subroutine calls" above? I changed it from calls to subroutine calls because the topics did not appear to match.D: yes, that's what I meant, please remove this after reading

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, metadata (data that describes the actual data) in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README describes this data.

SOA also does not limit the protocol used to transfer the data and a wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

!!!! It may be a good idea to add a graphical example of a SOA here

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language.

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming.

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes on dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

=='''How it is all related'''==

=='''Enhancing SOA'''==

Service-oriented Architecture becomes greatly effective when the underlying programs are able to dynamically adapt to the data received. Two very important concepts support this principles that SOA is build upon:

The concept of reflection can be used to extend the service being provided by a system in a Service-oriented Architecture by allowing the transfered data to modify the behavior.

=='''Appendix'''==

[http://en.wikipedia.org/wiki/Metadata '''Metadata'''] - data that describes the actual data

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of Reflection

!!!! Remove the title below if we do not have any good external links.
== Useful External Links ==
'''

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-09T00:52:41Z

Ncsueng:

!!!! I have copied things that help with formatting the page from my prior wiki. Feel free to add in anything that you think may help with formatting from your project.

!!!! Main topic (to keep us on track):

!!!! Note: Delete all the !!!! parts when done. These are notes while developing the wiki.

!!!! SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. To provide services, platforms rely upon principles and the power that can be expressed through reflection and meta programming. Research and report how these critical concepts relate to and support SOA.

!!!! Reword the following paragraph to "sound better".D: I am not sure if it sounds better, but here's my first pass at it. I'm not sure what verb should go in place of 'solve'

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article describes how this is possible and '''solves??''' three goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated.
#Examines how reflection and metaprogramming supports SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architectures'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This is generally accomplished with by passing messages [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

!!!! If we can, find a way to make the footnote in brackets, without brackets will probably work though.
!!!! Did you intend to say "subroutine calls" above? I changed it from calls to subroutine calls because the topics did not appear to match.D: yes, that's what I meant, please remove this after reading

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, metadata (data that describes the actual data) in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README describes this data.

SOA also does not limit the protocol used to transfer the data and a wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

!!!! It may be a good idea to add a graphical example of a SOA here

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language.

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming.

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes on dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

=='''How it is all related'''==

!!!! Explain

=='''Enhancing SOA'''==

Service-oriented Architecture becomes greatly effective when the underlying programs are able to dynamically adapt to the data received. Two very important concepts support this principles that SOA is build upon:

#[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] - Programs that write and manipulate other programs
#The concept of reflection can be used to extend the service being provided by a system in a Service-oriented Architecture by allowing the transfered data to modify the behavior.

=='''Appendix'''==

[http://en.wikipedia.org/wiki/Metadata '''Metadata'''] - data that describes the actual data

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of Reflection

!!!! Remove the title below if we do not have any good external links.
== Useful External Links ==
'''

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-09T00:42:20Z

Ncsueng:

!!!! I have copied things that help with formatting the page from my prior wiki. Feel free to add in anything that you think may help with formatting from your project.

!!!! Main topic (to keep us on track):

!!!! Note: Delete all the !!!! parts when done. These are notes while developing the wiki.

!!!! SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. To provide services, platforms rely upon principles and the power that can be expressed through reflection and meta programming. Research and report how these critical concepts relate to and support SOA.

!!!! Reword the following paragraph to "sound better".D: I am not sure if it sounds better, but here's my first pass at it

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how services can can be used to connect separate software components in a system. Reflection and metaprogramming are two concepts that directly support the principles of SOA. This article has three goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated.
#Examines how reflection and metaprogramming supports SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architectures'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This may be accomplished with the use of messages [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

!!!! If we can, find a way to make the footnote in brackets, without brackets will probably work though.
!!!! Did you intend to say "subroutine calls" above? I changed it from calls to subroutine calls because the topics did not appear to match.D: yes, that's what I meant, please remove this after reading

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, metadata (data that describes the actual data) in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README describes this data.

SOA also does not limit the protocol used to transfer the data and a wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

!!!! It may be a good idea to add a graphical example of a SOA here

==='''Metaprogramming'''===

[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A [http://en.wikipedia.org/wiki/Compiler compiler] is an excellent of a metaprogram, it allows the programmer to code in a higher level language and then the compiler will convert that program into machine language.

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create [http://en.wikipedia.org/wiki/Mutator_method 'setters' and 'getters'] for the name attribute via metaprogramming.

==='''Reflection'''===

[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] is a specific type of meta-programming and emphasizes on dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

=='''How it is all related'''==

!!!! Explain

=='''Enhancing SOA'''==

Service-oriented Architecture becomes greatly effective when the underlying programs are able to dynamically adapt to the data received. Two very important concepts support this principles that SOA is build upon:

#[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] - Programs that write and manipulate other programs
#The concept of reflection can be used to extend the service being provided by a system in a Service-oriented Architecture by allowing the transfered data to modify the behavior.

=='''Appendix'''==

[http://en.wikipedia.org/wiki/Metadata '''Metadata'''] - data that describes the actual data

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of Reflection

!!!! Remove the title below if we do not have any good external links.
== Useful External Links ==
'''

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-09T00:26:23Z

Ncsueng:

!!!! I have copied things that help with formatting the page from my prior wiki. Feel free to add in anything that you think may help with formatting from your project.

!!!! Main topic (to keep us on track):

!!!! Note: Delete all the !!!! parts when done. These are notes while developing the wiki.

!!!! SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. To provide services, platforms rely upon principles and the power that can be expressed through reflection and meta programming. Research and report how these critical concepts relate to and support SOA.

!!!! Reword the following paragraph to "sound better".D: I am not sure if it sounds better, but here's my first pass at it

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how services can can be used to connect separate software components in a system. Reflection and metaprogramming are two concepts that directly support the principles of SOA. This article has three goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated.
#Examines how reflection and metaprogramming supports SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architectures'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This may be accomplished with the use of messages [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

!!!! If we can, find a way to make the footnote in brackets, without brackets will probably work though.
!!!! Did you intend to say "subroutine calls" above? I changed it from calls to subroutine calls because the topics did not appear to match.D: yes, that's what I meant, please remove this after reading

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, metadata (data that describes the actual data) in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README describes this data.

SOA also does not limit the protocol used to transfer the data and a wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

!!!! It may be a good idea to add a graphical example of a SOA here

==='''Metaprogramming'''===

!!!! Discuss metaprogramming
!!!! It may be good to include a programming example here

:*'''''Example''': Metaprogramming in Ruby [2]
class Person
attr_accessor :name
end

In the example above, attr_accessor is used to create 'setters' and 'getters' for the 'name' attribute via metaprogramming.

==='''Reflection'''===

Reflection is a specific type of meta-programming and emphasizes on dynamic program modification. The concept of reflection can be used to extend the service being provided by a system in a Service-oriented Architecture by allowing the transfered data to modify the behavior.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

=='''How it is all related'''==

!!!! Explain

=='''Enhancing SOA'''==

Service-oriented Architecture becomes greatly effective when the underlying programs are able to dynamically adapt to the data received. Two very important concepts support this principles that SOA is build upon:

#[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] - Programs that write and manipulate other programs
#[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] - Programs that modify their own behavior

=='''Appendix'''==

[http://en.wikipedia.org/wiki/Metadata '''Metadata'''] - data that describes the actual data

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of Reflection

!!!! Remove the title below if we do not have any good external links.
== Useful External Links ==
'''

CSC/ECE 517 Fall 2009/wiki2 17 va

2009-10-09T00:20:59Z

Ncsueng:

!!!! I have copied things that help with formatting the page from my prior wiki. Feel free to add in anything that you think may help with formatting from your project.

!!!! Main topic (to keep us on track):

!!!! Note: Delete all the !!!! parts when done. These are notes while developing the wiki.

!!!! SOA provides another view of providing functionality based upon services offered in terms of protocols and a specific API. To provide services, platforms rely upon principles and the power that can be expressed through reflection and meta programming. Research and report how these critical concepts relate to and support SOA.

!!!! Reword the following paragraph to "sound better".D: I am not sure if it sounds better, but here's my first pass at it

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture'' 3] (or SOA) describes how services can can be used to connect separate software components in a system. Reflection and metaprogramming are two concepts that directly support the principles of SOA. This article has three goals:
#Provides a simple understanding of reflection, metaprogramming, and SOA's.
#Explains how these concepts are interrelated.
#Examines how reflection and metaprogramming supports SOA's.

== '''Service Oriented Architecture (SOA), Reflection, and Metaprogramming''' ==

__TOC__

=='''An overview of the concepts'''==

==='''Service Oriented Architectures'''===

[http://en.wikipedia.org/wiki/Service-oriented_architecture ''Service Oriented Architecture''] (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making [http://en.wikipedia.org/wiki/Subroutine subroutine calls] to each other. This may be accomplished with the use of messages [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

!!!! If we can, find a way to make the footnote in brackets, without brackets will probably work though.
!!!! Did you intend to say "subroutine calls" above? I changed it from calls to subroutine calls because the topics did not appear to match.D: yes, that's what I meant, please remove this after reading

The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, metadata (data that describes the actual data) in the SOA must: [http://en.wikipedia.org/wiki/Service_oriented_architecture 3]

*Be easy to configure
*Provide an easy way to discover services
*Provide an easy way to incorporate services
*Remain coherent
*Preserve data integrity
*Be easy to manage

A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README describes this data.

SOA also does not limit the protocol used to transfer the data and a wide variety of technologies can be used including [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP], [http://en.wikipedia.org/wiki/Representational_State_Transfer REST] and [http://en.wikipedia.org/wiki/Remote_procedure_call RPC]. This is generally left for the programmer of the system.

!!!! It may be a good idea to add a graphical example of a SOA here

==='''Metaprogramming'''===

!!!! Discuss metaprogramming
!!!! It may be good to include a programming example here

:*'''''Example''': Metaprogramming in Ruby [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]

==='''Reflection'''===

Reflection is a specific type of meta-programming and emphasizes on dynamic program modification. The concept of reflection can be used to extend the service being provided by a system in a Service-oriented Architecture by allowing the transfered data to modify the behavior.

:*'''''Example''': Reflection in Perl [http://en.wikipedia.org/wiki/Reflection_(computer_science) 5]
# without reflection
my $foo = Foo->new();
$foo->hello();

# with reflection
my $class = "Foo";
my $method = "hello";
my $object = $class->new();
$object->$method();

In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.

=='''How it is all related'''==

!!!! Explain

=='''Enhancing SOA'''==

Service-oriented Architecture becomes greatly effective when the underlying programs are able to dynamically adapt to the data received. Two very important concepts support this principles that SOA is build upon:

#[http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming] - Programs that write and manipulate other programs
#[http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection] - Programs that modify their own behavior

=='''Appendix'''==

[http://en.wikipedia.org/wiki/Metadata '''Metadata'''] - data that describes the actual data

=='''References'''==
'''
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA

2. Thomas, Dave (2006). ''Programming Ruby, The Pragmatic Programmers' Guide''.

3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA

4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA

5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of Reflection

!!!! Remove the title below if we do not have any good external links.
== Useful External Links ==
'''