Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-21T05:00:25Z

Maverick: /* Principle of Small Interfaces */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
__TOC__

=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks (also known as Interfaces) with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size and scope of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

This principle results in a large number of interfaces, but that is fine if it makes the code modular and loosely coupled.

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by using an Interface, exposes methods to fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2) Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs the list of employees, then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:36:11Z

Maverick:

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
__TOC__

=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks (also known as Interfaces) with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size and scope of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

This principle results in a large number of interfaces, but that is fine if it makes the code modular and loosely coupled.

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2) Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs the list of employees, then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:33:58Z

Maverick: /* Compare and Conclude */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks (also known as Interfaces) with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size and scope of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

This principle results in a large number of interfaces, but that is fine if it makes the code modular and loosely coupled.

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2) Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs the list of employees, then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:33:32Z

Maverick: /* Compare and Conclude */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks (also known as Interfaces) with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size and scope of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

This principle results in a large number of interfaces, but that is fine if it makes the code modular and loosely coupled.

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2) Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:31:42Z

Maverick: /* Principle of Small Interfaces */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks (also known as Interfaces) with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size and scope of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

This principle results in a large number of interfaces, but that is fine if it makes the code modular and loosely coupled.

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:30:09Z

Maverick: /* Interface Segregation Principle */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks (also known as Interfaces) with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size and scope of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

This principle results in a large number of interfaces, but that is fine if it makes the code modular and loosely coupled.

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:28:14Z

Maverick: /* Introduction */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks (also known as Interfaces) with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size and scope of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:27:41Z

Maverick: /* Introduction */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks (also known as Interfaces) with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:18:57Z

Maverick: /* Compare and Conclude */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:16:52Z

Maverick:

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2]].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:15:19Z

Maverick: /* Compare and Conclude */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_8_ISPPSI#Violation_of_Modular_Protection section 3.2].

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:14:41Z

Maverick: /* Violation of Modular Continuity */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (like [http://hadoop.apache.org/ Hadoop]), may not need this SQL Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:14:08Z

Maverick: /* Violation of Modular Continuity */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the <code>dbConnection</code> of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like [http://hadoop.apache.org/ Hadoop]), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:12:57Z

Maverick: /* Principle of Small Interfaces */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of ''Modular Protection'' and ''Modular Continuity''. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like [http://hadoop.apache.org/ Hadoop]), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:12:33Z

Maverick: /* Clients Should not be forced to use Interface they don't use */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which <code>work()</code> is used and during lunch break <code>eat()</code> is used. But if we try to implement a robot, then we are forced to use <code>eat()</code> on robot also though it is not using it. We are forcing robot to use <code>eat()</code> which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like [http://hadoop.apache.org/ Hadoop]), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:10:23Z

Maverick: /* References */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like [http://hadoop.apache.org/ Hadoop]), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
1. [http://www.oodesign.com/interface-segregation-principle.html OODesign.com]

2. [http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle on the ObjectMentor.com]

3. [http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden's blog]

4. [http://www2.lib.ncsu.edu/catalog/record/NCSU960289 Object-Oriented Software Construction. by Meyer, Bertrand]

4. [http://www.mihswat.com/2008/11/27/good-software-modularity-what-exactly-is-it/ "Good software modularity. What exactly is it?" by Otavio Ferreira]

5. [http://userpages.umbc.edu/~khoo/survey2.html "A Survey of Major Software Design Methodologies"]

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:04:06Z

Maverick: /* Violation of Modular Continuity */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like [http://hadoop.apache.org/ Hadoop]), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:03:24Z

Maverick: /* Compare and Conclude */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:02:14Z

Maverick: /* Compare and Conclude */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

1) Interface Segregation Principle:

\t By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

\t By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:02:00Z

Maverick: /* Compare and Conclude */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

1) Interface Segregation Principle:

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

2)Principle of Small Interfaces:

By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:01:25Z

Maverick: /* Interface Segregation Principle */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

==Principle of Small Interfaces==
By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T04:00:57Z

Maverick: /* Compare and Conclude */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=
At the outset it seems both the principles deal in recommend in using small interfaces by giving different guidelines. But a finer comparison can be made based on the code in section 3.2.

== Interface Segregation Principle==
By applying the Interface Segregation Principle, the need for removal of the <code>getEmployeeMap</code> cannot be argued. The method can be used by the clients to make one Database request and save it with the client so that the lookup can be done without any further call (The flip side is though client may not have an updated list of employees, which in any case will not change frequently.).

==Principle of Small Interfaces==
By applying Principle of Small Interfaces, we have already identified that the <code>getEmployeeMap</code> method is not required. If the client needs then there could be as many database calls as required and make its own list of required employees and not have redundant data.

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T03:53:32Z

Maverick: /* Interface Segregation Principle */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."

The rational for the principle can argued by the following points.

* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T03:52:43Z

Maverick: /* Interface Segregation Principle */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
The principle states that:
"The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use."
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T03:51:13Z

Maverick: /* Conclusion */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Compare and Conclude=

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T03:18:17Z

Maverick: /* Violation of Modular Protection */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method <code>getEmployeeMap</code> will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

This is a violation of the principle of Modular Protection which could have been avoided by blocking the communication channel via the <code>getEmployeeMap</code>, based on the Principle of Small Interfaces.

=Conclusion=

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T03:16:07Z

Maverick: /* Violation of Modular Protection */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

In this case the method getEmployeeMap will return the entire Hashmap of the employees where as all was required was a search operation based on some criteria. This exposes more data than is required by the clients and will allow them to access it and modify it case of [http://www.javaranch.com/journal/2003/04/immutable.htm mutable objects].

=Conclusion=

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T03:12:12Z

Maverick: /* Violation of Modular Protection */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

=Conclusion=

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T03:11:21Z

Maverick: /* Violation of Modular Protection */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {

private Connection dbConnection;
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public Connection getDbConnection() {
return dbConnection;
}

public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
return null;
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

=Conclusion=

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T03:11:00Z

Maverick: /* Principle of Small Interfaces */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
OO languages are inherently modular in structure. The functioning mechanism of the code is via the interaction of each of these modules or blocks with each other. The design of the modules is driven by the following restrictions imposed on them:

1.'''Modular Decomposability''' – A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.

2.'''Modular Composability''' – A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.

3.'''Modular Understandability''' – A software construction method satisfies Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.

4.'''Modular Continuity''' – A software construction method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.

5.'''Modular Protection''' – A software construction method satisfies Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules.

Of these the last two talk about the size of the Interfaces. In this article we will try to cover and explain two principles that give developer a guideline on the size content of an Interface and the redundancy in the methods that one should avoid so that we get a loosely coupled architecture flexible in enough to work with minimal code change.

Please refer the sections below.

=Interface Segregation Principle=
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

Consider an Interface shown below
interface Iworker{
public void work();
public void eat();
}

If we try to implement a class worker using above interface, the worker is allocated some time for working during which work() is used and during lunch break eat() is used. But if we try to implement a robot, then we are forced to use eat() on robot also though it is not using it. We are forcing robot to use eat() which is not being used.

So we have to use different type of interface which doesn't force interfaces on clients which are not used. The following code explains it.

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Principle of Small Interfaces=
The principle states that:

“If two modules communicate, they should exchange as little information as possible”

This principle is driven by the earlier mentioned rules of “Modular Protection” and “Modular Continuity”. If a system communicating with a client by an Interface exposes methods of fetch more information than needed, then there is chance of corruption of the common data that is not required by the system. Consider the following example which will illustrate the concept:

public class EmployeeLookupService {
public List getEmployeesForNameDOB(String lastName, Date birthDate)
// implementation …
return null;
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

This class helps in looking up an employee of the company. This is a simple example which adheres to the principle of small interfaces. The business requirements are to provide two search methods based on employee ID and Last Name – Date of Birth.

==Violation of Modular Continuity==

Consider the following code snippet which is another implementation of the similar business requirement.

public class EmployeeLookupService {
private Connection dbConnection;

public Connection getDbConnection() {
return dbConnection;
}
public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}
public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
}
public Employee getEmployeeForID(int employeeId) {
// implementation…
}
public void saveEmployee(Employee emp) {
// implementation…
}
}

In this above code the ''dbConnection'' of the type ''java.sql.connection'' is needed but for the internal usage of the Service. There is no need for the clients to be aware of it, or implement the getter and setter methods. If say one is using [http://java.sun.com/docs/books/tutorial/jdbc/ JDBC], then the connection object makes sense, but if a business decided to use [http://en.wikipedia.org/wiki/Mainframe_computer Mainframes] or any other [http://stackoverflow.com/questions/677253/what-are-alternatives-to-sql-database-storage-for-a-web-site non SQL] databases (Like http://hadoop.apache.org/ Hadoop), may not need this Sql Connection object at all.

This example is the called as violation of Modular Continuty, as the change in the business requirements has an impact of the client classes whereas if the Service was designed based on Principle of Small Interfaces, redundant communication channels could have been not developed, making the code resuable and more flexible.

==Violation of Modular Protection==

This violation is caused by giving access to common or more data than required by exposing methods by an interface. Consider the code snippet below.

public class EmployeeLookupService {

private Connection dbConnection;
private HashMap employeeMap;

public HashMap getEmployeeMap() {
return employeeMap;
}
public Connection getDbConnection() {
return dbConnection;
}

public void setDbConnection(Connection newDBConnection) {
dbConnection = newDBConnection;
}

public List getEmployeesForNameDOB(String lastName, Date birthDate) {
// implementation …
return null;
}

public Employee getEmployeeForID(int employeeId) {
// implementation…
return null;
}

public void saveEmployee(Employee emp) {
// implementation…
}
}

=Conclusion=

=References=
http://www.oodesign.com/interface-segregation-principle.html

http://www.objectmentor.com/resources/articles/isp.pdf

http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T02:46:56Z

Maverick:

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-19T02:35:00Z

Maverick: /* Introduction */

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-17T20:18:52Z

Maverick: /* Interface Segregation Principle */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
This page tries to review Integrated Development Environments for Ruby such as Aptana,Rubymine and Netbeans. Also the IDEs are compared with respect to certain dimensions such as facilities, ease of use, system requirements, and support for the Ruby way of thinking.

=Interface Segregation Principle=
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of a real system where the Interface-Segregation Principle is required to make the client usage simple.

Consider a User interface for ATM machine with a UI that allows conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

The end goal is to have a seamless user experience for a user with a fast turnaround time. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Comparision of Aptana,Netbeans and Rubymine=

Three IDEs namely Aptana's Radrails, Netbeans and Rubymine are compared in the following sections.
==System Requirements==

==Features for Ruby==

=Other Features available in IDE's=

=Conclusion=

=References=

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-17T20:14:36Z

Maverick: /* Interface Segregation Principle */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
This page tries to review Integrated Development Environments for Ruby such as Aptana,Rubymine and Netbeans. Also the IDEs are compared with respect to certain dimensions such as facilities, ease of use, system requirements, and support for the Ruby way of thinking.

=Interface Segregation Principle=
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of the Interface-Segregation Principle. Consider a User interface for ATM machine, where it may logically stand to reason you may have separate interfaces for a person conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need and in turn cause confusion to the final client.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Comparision of Aptana,Netbeans and Rubymine=

Three IDEs namely Aptana's Radrails, Netbeans and Rubymine are compared in the following sections.
==System Requirements==

==Features for Ruby==

=Other Features available in IDE's=

=Conclusion=

=References=

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-17T20:13:51Z

Maverick: /* Interface Segregation Principle */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
This page tries to review Integrated Development Environments for Ruby such as Aptana,Rubymine and Netbeans. Also the IDEs are compared with respect to certain dimensions such as facilities, ease of use, system requirements, and support for the Ruby way of thinking.

=Interface Segregation Principle=
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of the Interface-Segregation Principle. Consider a User interface for ATM machine, where it may logically stand to reason you may have separate interfaces for a person conducting a

1) Deposit Transaction,

2) Withdrawal Transaction, and

3) Transfer Transaction.

You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Comparision of Aptana,Netbeans and Rubymine=

Three IDEs namely Aptana's Radrails, Netbeans and Rubymine are compared in the following sections.
==System Requirements==

==Features for Ruby==

=Other Features available in IDE's=

=Conclusion=

=References=

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-17T20:09:40Z

Maverick: /* Clients Should not be forced to use Interface they don't use */

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''
----
=Introduction=
This page tries to review Integrated Development Environments for Ruby such as Aptana,Rubymine and Netbeans. Also the IDEs are compared with respect to certain dimensions such as facilities, ease of use, system requirements, and support for the Ruby way of thinking.

=Interface Segregation Principle=
* “Many client specific interfaces are better than one general purpose interface“
* “The dependency of one class to another one should depend on the smallest possible interface“
* “Make fine grained interfaces that are client specific.“
* “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Here is an example of the Interface-Segregation Principle. Consider a User interface for ATM machine, where it may logically stand to reason you may have separate interfaces for a person conducting a 1) Deposit Transaction, 2) Withdrawal Transaction, and 3) Transfer Transaction. You would definitely separate these 3 interfaces from each other so that one type of transaction does not depend on functions it does not need.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

==Clients Should not be forced to use Interface they don't use==

To explain this consider the following Java Code

interface IWorker extends Feedable, Workable {
}
interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in launch break
}
}

class Robot implements IWorkable{
public void work() {
// ....working
}
}

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in launch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}

=Comparision of Aptana,Netbeans and Rubymine=

Three IDEs namely Aptana's Radrails, Netbeans and Rubymine are compared in the following sections.
==System Requirements==

==Features for Ruby==

=Other Features available in IDE's=

=Conclusion=

=References=

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-17T18:32:01Z

Maverick:

'''''Interface Segregation Principle vs. Principle of Small Interfaces'''''

CSC/ECE 517 Fall 2009/wiki3 8 ISPPSI

2009-11-17T18:27:22Z

Maverick:

Interface Segregation Principle vs. Principle of Small Interfaces

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-14T03:01:21Z

Maverick:

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end

def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
end
end

createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end

def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
The code by use of this library is just like one-one mapping between the Domain object and the elements of the XML.

====WSDL, SOAP and UDDI in Ruby====
Consider the following example of a [http://www.brics.dk/~amoeller/WWW/webservices/wsdlexample.html wsdl file].
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

This file is parsed by using the REXML api and then using the '''''SOAP4R''''' library one can invoke the service. One can also use '''''WSDL4R''''' library to directly create the Ruby code for identifying the Name of the service, the elements and I/O objects. Below is a sample code on how a SOAP call is made using the SOAP4R library

class ServiceRequestController < ApplicationController
@apiKey = "StockQuoteService"
def requestAService
@wsdlUrl = "abc"
driver = SOAP::WSDLDriverFactory.new(@wsdlUrl).create_rpc_driver
driver.add_method('GetLastTradePriceInput',:tradePriceRequestObject)
driver.GetLastTradePriceInput(tradePriceRequestObject)
end
end

Here the method name is found by parsing the wsdl file to get the '''message name'''. The children of this node are the parameters and o/p that the method returns.
Thus by using <code>add_method</code> one could dynamically add a method to a class and invoke it.

The WSDL4R is packaged with SOAP4R library. This is because all the information needed for invoking a service is same and one can have a same implementation for all the services. This is made possible due to the DuckTyping nature of Ruby.

UDDI is one link that is not yet discussed. As mentioned earlier there has to be one single place where one can find all the information for the service if one is going to communicate with different businesses. The below sample code illustrates how the list of businesses and the services that are available and can be looked up [http://uddi4r.rubyforge.org/ ]

require "lib/client"

# create the client
uddi = Uddi4r::Client.new("http://uddi.xmethods.net/inquire")

# find first matching business
list = uddi.find_business(:name=>"chaiwat")
biz = list.business_infos.first()

# find first service
service = biz.service_infos.first()

# and it's binding
binding = uddi.find_binding(service.service_key)
template = binding.binding_template.first()
puts template.access_point()

This uses the UDDI4R library to parse the UDDI registry given by http://uddi.xmethods.net/inquire and identify the Business names and the services. Once Identified one can use the SOAP4R or WSDL4R libraries to make the remote calls.

==Conclusion==
Reflection and Meta programming assist the implementation of the SOA philosophy. On the outset, it seems as if Metaprogramming and reflection are the different names for the same thing, but it will be safe to say that Reflection is a stronger form of Metaprogramming. As metaprogramming and reflection are powerful, so is their resource utilization. One has to take extreme caution and should use Reflection when the situation warrants for no other technique. Even while implementing SOA, the components that are on the web-services tier i.e. the tier which communicates with the external consumers or service providers, should be implemented using the reflection.

==References==
1] SOA with Ruby at �erubycon on �July 18, 2007 by Zak Mandhro �Senior Manager �BearingPoint, Inc

2] [http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html SOA and Web Services]

3] Programming Ruby 1.9 by Dave Thomas, with Chad Fowler and Andy Hunt

4] [http://soa.sys-con.com/node/39831 Web Services Made Easy]

5] Ruby On Rails Power By Aneesha Bakharia

6] Rails for Java Developers

7] [http://en.wikipedia.org/wiki/Reflection_(computer_science) Reflection Oriented Programming]

8] [http://nvisia.com/techs/?p=42 Shortcomings of Reflection]

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-11T02:07:19Z

Maverick: /* WSDL, SOAP and UDDI in Ruby */

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
The code by use of this library is just like one-one mapping between the Domain object and the elements of the XML.

====WSDL, SOAP and UDDI in Ruby====
Consider the following example of a [http://www.brics.dk/~amoeller/WWW/webservices/wsdlexample.html wsdl file].
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

This file is parsed by using the REXML api and then using the '''''SOAP4R''''' library one can invoke the service. One can also use '''''WSDL4R''''' library to directly create the Ruby code for identifying the Name of the service, the elements and I/O objects. Below is a sample code on how a SOAP call is made using the SOAP4R library

class ServiceRequestController < ApplicationController
@apiKey = "StockQuoteService"
def requestAService
@wsdlUrl = "abc"
driver = SOAP::WSDLDriverFactory.new(@wsdlUrl).create_rpc_driver
driver.add_method('GetLastTradePriceInput',:tradePriceRequestObject)
driver.GetLastTradePriceInput(tradePriceRequestObject)
end
end

Here the method name is found by parsing the wsdl file to get the '''message name'''. The children of this node are the parameters and o/p that the method returns.
Thus by using <code>add_method</code> one could dynamically add a method to a class and invoke it.

The WSDL4R is packaged with SOAP4R library. This is because all the information needed for invoking a service is same and one can have a same implementation for all the services. This is made possible due to the DuckTyping nature of Ruby.

UDDI is one link that is not yet discussed. As mentioned earlier there has to be one single place where one can find all the information for the service if one is going to communicate with different businesses. The below sample code illustrates how the list of businesses and the services that are available and can be looked up [http://uddi4r.rubyforge.org/ ]

require "lib/client"

# create the client
uddi = Uddi4r::Client.new("http://uddi.xmethods.net/inquire")

# find first matching business
list = uddi.find_business(:name=>"chaiwat")
biz = list.business_infos.first()

# find first service
service = biz.service_infos.first()

# and it's binding
binding = uddi.find_binding(service.service_key)
template = binding.binding_template.first()
puts template.access_point()

This uses the UDDI4R library to parse the UDDI registry given by http://uddi.xmethods.net/inquire and identify the Business names and the services. Once Identified one can use the SOAP4R or WSDL4R libraries to make the remote calls.

==References==
1] SOA with Ruby at �erubycon on �July 18, 2007 by Zak Mandhro �Senior Manager �BearingPoint, Inc

2] [http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html SOA and Web Services]

3] Programming Ruby 1.9 by Dave Thomas, with Chad Fowler and Andy Hunt

4] [http://soa.sys-con.com/node/39831 Web Services Made Easy]

5] Ruby On Rails Power By Aneesha Bakharia

6] Rails for Java Developers

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-10T04:54:21Z

Maverick: /* References */

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API
API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
The code by use of this library is just like one-one mapping between the Domain object and the elements of the XML.

===WSDL, SOAP and UDDI in Ruby===
Consider the following example of a [http://www.brics.dk/~amoeller/WWW/webservices/wsdlexample.html wsdl file].
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

This file is parsed by using the REXML api and then using the '''''SOAP4R''''' library one can invoke the service. One can also use '''''WSDL4R''''' library to directly create the Ruby code for identifying the Name of the service, the elements and I/O objects. Below is a sample code on how a SOAP call is made using the SOAP4R library

class ServiceRequestController < ApplicationController
@apiKey = "StockQuoteService"
def requestAService
@wsdlUrl = "abc"
driver = SOAP::WSDLDriverFactory.new(@wsdlUrl).create_rpc_driver
driver.add_method('GetLastTradePriceInput',:tradePriceRequestObject)
driver.GetLastTradePriceInput(tradePriceRequestObject)
end
end

Here the method name is found by parsing the wsdl file to get the '''message name'''. The children of this node are the parameters and o/p that the method returns.
Thus by using <code>add_method</code> one could dynamically add a method to a class and invoke it.

The WSDL4R is packaged with SOAP4R library. This is because all the information needed for invoking a service is same and one can have a same implementation for all the services. This is made possible due to the DuckTyping nature of Ruby.

UDDI is one link that is not yet discussed. As mentioned earlier there has to be one single place where one can find all the information for the service if one is going to communicate with different businesses. The below sample code illustrates how the list of businesses and the services that are available and can be looked up [http://uddi4r.rubyforge.org/ ]

require "lib/client"

# create the client
uddi = Uddi4r::Client.new("http://uddi.xmethods.net/inquire")

# find first matching business
list = uddi.find_business(:name=>"chaiwat")
biz = list.business_infos.first()

# find first service
service = biz.service_infos.first()

# and it's binding
binding = uddi.find_binding(service.service_key)
template = binding.binding_template.first()
puts template.access_point()

This uses the UDDI4R library to parse the UDDI registry given by http://uddi.xmethods.net/inquire and identify the Business names and the services. Once Identified one can use the SOAP4R or WSDL4R libraries to make the remote calls.

==References==
1] SOA with Ruby at �erubycon on �July 18, 2007 by Zak Mandhro �Senior Manager �BearingPoint, Inc

2] [http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html SOA and Web Services]

3] Programming Ruby 1.9 by Dave Thomas, with Chad Fowler and Andy Hunt

4] [http://soa.sys-con.com/node/39831 Web Services Made Easy]

5] Ruby On Rails Power By Aneesha Bakharia

6] Rails for Java Developers

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-10T04:11:32Z

Maverick:

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API
API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
The code by use of this library is just like one-one mapping between the Domain object and the elements of the XML.

===WSDL, SOAP and UDDI in Ruby===
Consider the following example of a [http://www.brics.dk/~amoeller/WWW/webservices/wsdlexample.html wsdl file].
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

This file is parsed by using the REXML api and then using the '''''SOAP4R''''' library one can invoke the service. One can also use '''''WSDL4R''''' library to directly create the Ruby code for identifying the Name of the service, the elements and I/O objects. Below is a sample code on how a SOAP call is made using the SOAP4R library

class ServiceRequestController < ApplicationController
@apiKey = "StockQuoteService"
def requestAService
@wsdlUrl = "abc"
driver = SOAP::WSDLDriverFactory.new(@wsdlUrl).create_rpc_driver
driver.add_method('GetLastTradePriceInput',:tradePriceRequestObject)
driver.GetLastTradePriceInput(tradePriceRequestObject)
end
end

Here the method name is found by parsing the wsdl file to get the '''message name'''. The children of this node are the parameters and o/p that the method returns.
Thus by using <code>add_method</code> one could dynamically add a method to a class and invoke it.

The WSDL4R is packaged with SOAP4R library. This is because all the information needed for invoking a service is same and one can have a same implementation for all the services. This is made possible due to the DuckTyping nature of Ruby.

UDDI is one link that is not yet discussed. As mentioned earlier there has to be one single place where one can find all the information for the service if one is going to communicate with different businesses. The below sample code illustrates how the list of businesses and the services that are available and can be looked up [http://uddi4r.rubyforge.org/ ]

require "lib/client"

# create the client
uddi = Uddi4r::Client.new("http://uddi.xmethods.net/inquire")

# find first matching business
list = uddi.find_business(:name=>"chaiwat")
biz = list.business_infos.first()

# find first service
service = biz.service_infos.first()

# and it's binding
binding = uddi.find_binding(service.service_key)
template = binding.binding_template.first()
puts template.access_point()

This uses the UDDI4R library to parse the UDDI registry given by http://uddi.xmethods.net/inquire and identify the Business names and the services. Once Identified one can use the SOAP4R or WSDL4R libraries to make the remote calls.

==References==
1] SOA with Ruby at �erubycon on �July 18, 2007 by Zak Mandhro �Senior Manager �BearingPoint, Inc
2] [http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html SOA and Web Services]
3] Programming Ruby 1.9 by Dave Thomas, with Chad Fowler and Andy Hunt
4] [http://soa.sys-con.com/node/39831 Web Services Made Easy]
5] Ruby On Rails Power By Aneesha Bakharia
6] Rails for Java Developers

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-10T04:06:02Z

Maverick: /* WSDL, SOAP and UDDI in Ruby */

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API
API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
The code by use of this library is just like one-one mapping between the Domain object and the elements of the XML.

===WSDL, SOAP and UDDI in Ruby===
Consider the following example of a [http://www.brics.dk/~amoeller/WWW/webservices/wsdlexample.html wsdl file].
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

This file is parsed by using the REXML api and then using the '''''SOAP4R''''' library one can invoke the service. One can also use '''''WSDL4R''''' library to directly create the Ruby code for identifying the Name of the service, the elements and I/O objects. Below is a sample code on how a SOAP call is made using the SOAP4R library

class ServiceRequestController < ApplicationController
@apiKey = "StockQuoteService"
def requestAService
@wsdlUrl = "abc"
driver = SOAP::WSDLDriverFactory.new(@wsdlUrl).create_rpc_driver
driver.add_method('GetLastTradePriceInput',:tradePriceRequestObject)
driver.GetLastTradePriceInput(tradePriceRequestObject)
end
end

Here the method name is found by parsing the wsdl file to get the '''message name'''. The children of this node are the parameters and o/p that the method returns.
Thus by using <code>add_method</code> one could dynamically add a method to a class and invoke it.

The WSDL4R is packaged with SOAP4R library. This is because all the information needed for invoking a service is same and one can have a same implementation for all the services. This is made possible due to the DuckTyping nature of Ruby.

UDDI is one link that is not yet discussed. As mentioned earlier there has to be one single place where one can find all the information for the service if one is going to communicate with different businesses. The below sample code illustrates how the list of businesses and the services that are available and can be looked up [http://uddi4r.rubyforge.org/ ]

require "lib/client"

# create the client
uddi = Uddi4r::Client.new("http://uddi.xmethods.net/inquire")

# find first matching business
list = uddi.find_business(:name=>"chaiwat")
biz = list.business_infos.first()

# find first service
service = biz.service_infos.first()

# and it's binding
binding = uddi.find_binding(service.service_key)
template = binding.binding_template.first()
puts template.access_point()

This uses the UDDI4R library to parse the UDDI registry given by http://uddi.xmethods.net/inquire and identify the Business names and the services. Once Identified one can use the SOAP4R or WSDL4R libraries to make the remote calls.

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-10T03:53:26Z

Maverick: /* WSDL, SOAP and UDDI in Ruby */

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API
API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
The code by use of this library is just like one-one mapping between the Domain object and the elements of the XML.

===WSDL, SOAP and UDDI in Ruby===
Consider the following example of a [http://www.brics.dk/~amoeller/WWW/webservices/wsdlexample.html wsdl file].
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

This file is parsed by using the REXML api and then using the '''''SOAP4R''''' library one can invoke the service. One can also use '''''WSDL4R''''' library to directly create the Ruby code for identifying the Name of the service, the elements and I/O objects. Below is a sample code on how a SOAP call is made using the SOAP4R library

class ServiceRequestController < ApplicationController
@apiKey = "StockQuoteService"
def requestAService
@wsdlUrl = "abc"
driver = SOAP::WSDLDriverFactory.new(@wsdlUrl).create_rpc_driver
driver.add_method('GetLastTradePriceInput',:tradePriceRequestObject)
driver.GetLastTradePriceInput(tradePriceRequestObject)
end
end

Here the method name is found by parsing the wsdl file to get the '''message name'''. The children of this node are the parameters and o/p that the method returns.
Thus by using <code>add_method</code> one could dynamically add a method to a class and invoke it.

The WSDL4R is packaged with SOAP4R library. This is because all the information needed for invoking a service is same and one can have a same implementation for all the services. This is made possible due to the DuckTyping nature of Ruby.

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-10T03:49:59Z

Maverick: /* WSDL, SOAP and UDDI in Ruby */

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API
API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
The code by use of this library is just like one-one mapping between the Domain object and the elements of the XML.

===WSDL, SOAP and UDDI in Ruby===
Consider the following example of a [http://www.brics.dk/~amoeller/WWW/webservices/wsdlexample.html wsdl file].
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

This file is parsed by using the REXML api for one can use '''''WSDL4R''''' library to directly create the Ruby code for identifying the Name of the service, the elements and I/O objects. Below is a sample code on how a SOAP call is made:

class ServiceRequestController < ApplicationController
@apiKey = "StockQuoteService"
def requestAService
@wsdlUrl = "abc"
driver = SOAP::WSDLDriverFactory.new(@wsdlUrl).create_rpc_driver
driver.add_method('GetLastTradePriceInput',:tradePriceRequestObject)
driver.GetLastTradePriceInput(tradePriceRequestObject)
end
end

Here the method name is found by parsing the wsdl file to get the '''message name'''. The children of this node are the parameters and o/p that the method returns.
Thus by using <code>add_method</code> one could dynamically add a method to a class and invoke it.

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-10T03:36:11Z

Maverick: /* WSDL, SOAP and UDDI in Ruby */

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API
API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
The code by use of this library is just like one-one mapping between the Domain object and the elements of the XML.

===WSDL, SOAP and UDDI in Ruby===
Consider the following example of a wsdl file.
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-10T03:35:30Z

Maverick: /* SOAP */

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API
API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
The code by use of this library is just like one-one mapping between the Domain object and the elements of the XML.

===WSDL, SOAP and UDDI in Ruby===
Consider the following example of a wsdl file.
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-10T03:32:52Z

Maverick: /* XML Parsing */

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API
API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
The code by use of this library is just like one-one mapping between the Domain object and the elements of the XML.

===SOAP===

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-10T03:31:25Z

Maverick: /* == */

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API
API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.

CSC/ECE 517 Fall 2009/wiki2 17 f1

2009-10-10T03:31:14Z

Maverick: /* XML Parsing */

'''Service Oriented Architecture 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.'''

== Service Oriented Architectures==
Service Oriented Architecture is not a new thing, but has been there since around 1991 by virtue of the [http://www.omg.org/gettingstarted/history_of_corba.htm CORBA specifications]. The earliest SOA architectures were, DCOM and CORBA [http://www.service-architecture.com/web-services/articles/prior_service-oriented_architecture_specifications.html 1]. [http://en.wikipedia.org/wiki/Service_Oriented_Architectures Service Oriented Architecture] (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. SOA provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. It is a collection of services. These services communicate with each other either by simple data passing or it could involve two or more services coordinating some activity by means of some predefined standard connecting services. This makes it easier for software integration of different modules developed by different people. Rather than defining an [http://en.wikipedia.org/wiki/API
API], SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together.
The typical SOA implementation can be illustrated in the figure:

[[Image:Service-oriented_architecture_basics.jpg|SOA Functioning]]

The main characteristics of SOA are:

* '''Based on open standards''' - The governing principles are free for all to use and not protected by intellectual property.
* '''Interoperable''' - Diverse systems should be able to work together (inter-operate)
* '''Autonomous''' - Services have control over the logic they encapsulate.
* '''Reusable''' - Logic is divided into services with the intention of promoting reuse.
* '''Reliable''' - It should not have many flaws
* '''Discoverable''' - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
* '''Loosely-Coupled''' - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
* '''Stateless''' - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
* '''Composable''' - Collections of services can be coordinated and assembled to form composite services.
* '''Manageable''' - It should be easy to maintain it
* '''Secure''' - It should not be easily hackable

=== Core Components of SOA===
As mentioned earlier, the services communicate with each other using a predefined protocol. The techniques used for protocol selection and execution form the core components of SOA. While using SOA, we have a service that has tells the type of service its provides using [http://en.wikipedia.org/wiki/Web_Services_Description_Language Web Services Description Language (WSDL)] and a directory, like [http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_uddi.html Universal Description, Discovery, and Integration (UDDI)] that holds this information. The service consumer (one who wants some service) will lookup this directory for the name of the service that can fulfill the consumer's request. The consumer and the service provider communicate using some format (in layman terms a language) like SOAP. These ideology leads to the following components of a SOA implementation.

* '''SOAP''': Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an [http://en.wikipedia.org/wiki/XML XML]-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
* '''WSDL''': Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
* '''UDDI''': Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
* '''BPEL''': Business Process Execution Language - Its a language for specifying interaction with web services.
* '''ESB''': [http://en.wikipedia.org/wiki/Enterprise_service_bus Enterprise Service Bus]
* '''WS-*''': Web Services Standards - a collection of protocols and standards used for exchanging data between applications

===Benefits of SOA ===
The benefits offered by SOA can be directly derived from the characteristics of SOA. The features like loose coupling between the service requests and service provider implies flexibility and reuse of services for different service consumers. The benefits can be summarized as below:
* Improve long-term value of software assets
* Improve quality through modularity and testability
* Reduce development time with composition and re-usability
* Leverage heterogeneous development environments
* Avoid vendor and platform lock-in
* Integrate with [http://en.wikipedia.org/wiki/Enterprise_resource_planning ERPs] and Enterprise infrastructure software

===Use cases for SOA with Ruby===
Ruby can be a productive way to:
* Build web applications over web services
* Write web services tests with minimal code
* Write custom web services monitoring and management
* Integrate ERPs, [http://en.wikipedia.org/wiki/Commercial_off-the-shelf COTS] and custom applications
* Write SOA glue-code, e.g. custom transformation
* Perform programmatic web services orchestration
* Develop basic web services

==Reflection in Ruby==

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -
* what objects it contains,
* the class hierarchy,
* the attributes and methods of objects, and
* information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,
<pre>
ObjectSpace.each_object { |x| puts x }
</pre>
will print all living, nonimmediate objects in Ruby process.

<pre>
ObjectSpace.each_object(Class) { |x| puts x}
</pre>
will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.
<pre>
class ClassFromString
@@counter = 0
def initialize
@@counter += 1
end
def getCounterValue
puts @@counter
end
end

def createClassFromString(classname)
ObjectSpace.each_object(Class) do |x|
if x.name == classname
object = x.new
object.getCounterValue
object = x.new
object.getCounterValue
end
end
end
createClassFromString("ClassFromString")
</pre>

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically.
You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

'''Distributed Ruby''' and '''Marshalling''' are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

===Marshalling===

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed.
To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on.
Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method ''Marshal.dump''. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using ''Marshal.load''.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

<pre>

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

</pre>

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

<pre>

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

</pre>

Finally, it can be read by our friends.

<pre>
File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"
</pre>

=== Distributed Ruby ===
Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears
that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.

==Metaprogramming and SOA==
The non - dependence of service consumers with service providers during compile time causes a dynamic runtime binding. Invocation of a wide range of service providers calls for techniques that can help creation of service requests at runtime for compatibility with the binding identified during runtime. This can be achieved by using the technique of Metaprogramming. "Meta" means "self" and hence meta programming can be stated as self programming or program that codes itself. This means that there will be some set of code which will create code at runtime. Using this we can create code that binds the service consumer with service provider.
The concept of meta programming is explained by using Ruby language.

===Metaprogramming in Ruby===
Metaprogramming is inbuilt and used extensively by the language itself. Consider the following standard used syntax to create getters and setters in ruby:
"<code>attr_writer :a</code>", "<code>attr_reader :a</code>", "<code>attr_accessor :b</code>". Each of the single lines of code creates the accessor or/and mutators methods for the variables. This is an example of '''''Metaprogramming'''''. The logic written by the base ruby code (in <code>object.c</code> file in the ruby directory) uses the information about the variable name provided by the developer and creates at runtime the accessor and mutator methods. This is at runtime as physically there is no code which is present.
Metaprogramming is achieved by the <code>eval</code> method provided by the Ruby language.
class GreetPeople
eval %{def greeting puts "Hello All!" end}
end
me = GreetPeople.new
puts me.hi

''produces'' '''''Hello All!'''''

One can use <code>define_method</code> to generate classes and methods at runtime. The usage is like below
class Logger
def self.add_logging(id_string)
define_method(:log) do |msg|
now = Time.now.strftime("%H:%M:%S")
STDERR.puts "#{now}-#{id_string}: #{self} (#{msg})"
end
end
end

class Song < Logger
add_logging "Tune"
end

class Album < Logger
add_logging "CD"
end

song = Song.new
song.log("rock on")

The output produced is:
13:26:13-Tune: #<Song:0x0a20e4> (rock on)

Look the part <code>#<Song:0x0a20e4></code> even if there is no mention of the class Song, the logger method printed the name of the class as it picked it up at runtime from the keyword '''"self"'''.

Other methods like add_method adds method to the a class at runtime.

===SOA with Ruby===
Ruby has some standard libraries for each functional block in the SOA architecture. These libraries are
XML 1.0 - REXML, others
SOAP 1.1 - SOAP4R, AWS
WSDL 1.1 - WSDL4R, AWS
UDDI V2 - UDDI4R

Each of these libraries use Metaprogramming in some form or the other. Below is the description for each of the libraries
====XML Parsing====
XML is the foundation for the web services. The request, identification of service, method and its parameters of the service, the response, all are in the form of an xml. Thus XML parsing and construction is very important part for effective SOA implementation.
The XML parsing is handled by the REXML library which is coded in native Ruby code and hence is slow.

The sample code for parsing is
require 'rexml/document'
xml = "<xml><person>Abc Xyz</person></xml>
begin
REXML::Document.new(xml)
rescue REXML::ParseException
puts "Error occured"
end

At runtime the code identifies the nodes and children for each node which can be converted into a collections object for usage and identifying the names and values for each element.

While reading an XML, the use of REXML results in a complex piece of code. Life can be made much simpler by use of '''Builder::XmlMarkup''' libraries.
====