Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch6 6j ps

2010-11-27T01:20:45Z

Smkakara: /* '''Design Patterns associated with SOA''' */

'''SERVICE ORIENTED ARCHITECTURE'''
=='''Introduction'''==
[http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture] is an architectural approach to creating systems built using autonomous services. SOA brings the emphasis to integration of services and there orchestration to build applications. [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] usually seems like a natural development to all the existing methods to do enterprise wide integration of applications.
Concepts of SOA like services, discovery and late binding etc are from older [http://en.wikipedia.org/wiki/Middleware middle ware] solutions like [http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture CORBA]. The [[#design | design principles of SOA]] too are similar to the previously existing [http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design OOA/OOD ] techniques like encapsulation, abstraction and well defined interfaces.

=='''Need for SOA?'''==
Now we know the definition of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] from the previous section, with just the definition or 2 line statements we can't praise [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] . To praise and know the real power of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA], one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture.

Consider the example of banking system. Say the bank is currently handling credit card division, and it developed a software to handle all its transactions.
This software developed is a collection and interaction of various modules like getuserinformation, checking balance , check credit card history and process
payments and so on. Say at some later point of time,a bank started debit card division and again now to handle all its debit card related functionality
it needs one more software, this software has almost the same functionality as the credit card software, with some differences in functionality.
Now the possible solutions the bank can think of in developing the software for debit card division would be :-
* Take the same code and make changes to it: The problem with this approach is code duplication and maintainability. Say if a bug crops in one of the existing modules we now need to change at 2 places one in credit card software and another in debit card software. If company thinks of developing the debit card software using new programming language, then even code reuse is not possible.
* Object oriented approach of inheriting objects: One might say the bank can use Object oriented approach and derive class and functionalities and so on. Even then we have a problem with this approach, we can't alter the existing credit card software if we had to and even maintainability is problem over here. As discussed previously, if bank thinks of writing new software in a different programming language then this solution gets completely ruled out.
 
This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service. Each service communicates with other services and service consumers using data representation methods like [http://en.wikipedia.org/wiki/XML XML(extensible Markup Language)] as compared to function calls in the conventional programming languages. With this approach we have many advantages:

* Reusable code in the form of services: Code is reused in the form of services.
* Code is easily maintainable: As functionality is offered as a service and it is in a single place. It is also autonomous.
* Support for legacy functions: We can reuse legacy functions by writing wrapper around the functionality and make it interact with other services using XML.
* Platform and language independent services: as services interact with each other through XML so the service and the service consumer need not be in the same programming language.

Without SOA many functionalities needs to be duplicated and we face problems such as consistency,maintainability...
As it can be seen from the diagram below , with SOA all the repeated functionalities are made as a common service and are utilized by the consumers(credit card software and debit card software).
 
[[Image:Soa pics.jpg]]

=='''Technical jargons associated with SOA'''==
Before digging deep into [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] concepts like services ,design patterns associated with [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA ] , we need to understand some basic terminologies used in SOA.

Lets explain this using the above example itself.
# Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
# Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
# Directory services or Broker: - After each service is created it registers itself to directory service so that service can be easily located by the consumer of services. whenever consumer wants to utilize the functionality ,he will enquire the directory service and locate the service.
# Web Services:- web services make up a connection technology. It is a way to connect services together into a service-oriented architecture.
# Basic SOA MODEL:
[[Image:Basic_soa.gif|centre]]
This diagram explains the basic SOA model of publish/find/bind.In this model when a service is written it registers itself(publish) with the broker service , the broker is like a directory of service . Whenever a consumer of service, wants to use the functionality of a service he will enquire the directory and finds the information required to bind with the service.Once bind information is obtained , consumer will bind to the service.

<div id="design">

=='''Design principles of Services in SOA'''==
</div>
Services are the most important part of SOA , so now we will discuss about services and the design principles involved in it.Once we discuss principles of services we will ponder over advance topics in design of services - "Design patterns associated with SOA".
===[http://www.soaprinciples.com Overview of key principles of services]===
* '''Service Loose Coupling''' - According to this principle, services should be designed in such a way that it reduces the dependency of given service on other service.
* '''Service Abstraction''' - service should be like a black box, it should hide the implementation details from the outside world.
* '''Service Re-usability''' - services should be implemented in such a fashion that it should be more reusable.
* '''Service Statelessness''' - service should be implemented in such a fashion that it tries to minimize the amount of state information it stores. It should store the state information if it is really necessary.
* '''Service Discover-ability''' - Each service should be associated with meta data, this allows us to discover the service and what it does, its input requirements.
* '''Service Autonomy''' - For the service to work correctly and reliably it should have some amount of control on its underlying environment.According to this principle only limited autonomy is provided to the service such that it works correctly.

===Deep dive into the design principles of services===

Following are some of the key tenets that needs to be discussed in detail:-
 
*'''Boundaries are explicit''' 
A service's boundary is its interface to the outside world which is published using a [http://en.wikipedia.org/wiki/WSDL WSDL](Web Services Description Language). Principles that needs to be kept in mind while we design SOA systems and which come under this tenet are, ''Services should be easy to consume'' - that is a developer should be able to write software easily by consuming the services. ''The services should be designed keeping evolution in mind''.'' Services built should be granular so that they can be easily reused.
''
*'''Services are autonomous'''
Services are independently designed, implemented, deployed and version-ed. A designer should not make any assumptions about the service and its capabilities
other than what is provided by the contract. For example if a network latency was assumed and if the computer was moved to a new topology then the network
latency can change. Principles under this tenet a service designer should know are, We should be pessimistic about a service and its capabilities other than
the ones mentioned in the WSDL. We should also be pessimistic about the consumer of the services, so a lot error handling and compensation should be provided.
Services should be version-ed independent of the systems that consume them.
 
*'''Services share Schema and Contract, not Class''':
Make sure that a service contract remains stable and use the extensible properties of XML and [http://en.wikipedia.org/wiki/SOAP SOAP](optional headers) to add any exceptions. We are referring to the WSDL when we say contract in the above statement. Version services in case changes are unavoidable there by ensuring compliance to all the consumers.
 
*'''Service compatibility is based on policy''':
WSDL can communicate only syntactically for consuming a service. In many cases this is not good enough, especially to share semantic information about consuming the service. The service designer should use the WS-Policy standards for this and should not try to include this somehow into the [http://en.wikipedia.org/wiki/WSDL WSDL]. For example if the government is providing a service to identify miscreants by image comparison. If there is a compliance required from the consumers end about the size and quality of the photo to be used for comparison this should be taken care of using the WS-Policy requirements.
 
*'''[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling]''':
Coupling is a entity which tells us level of dependency that exists between program modules.Ideally speaking there should be zero coupling between modules.
Based on the level/degree of dependencies between modules we have different types of coupling like Content coupling (high), Data coupling, Message coupling (low) and
so on.Good service in SOA should exhibit low coupling as in message coupling
a)message coupling' - this is one of the loosest forms of coupling where in the calling function doesn't know the location of the recipient and has very less
knowledge of the recipient.
 
*'''[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion]'''
Another important concept that need to be discussed with respect to SOA is cohesion.Cohesion tells us about how the parts/sections in the service are related to
each other.Ideally modules should have very high cohesion.Good service in SOA should exhibit one of the following types of cohesion:
a)Functional Cohesion: Here module does only one thing , such type of services are highly reusable.
b)Sequential Cohesion: module does several tasks and that must be in order.
c)Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

In Summary, service we design should have loose coupling and have high cohesion.

=='''Design Patterns associated with SOA'''==
With the background of general [[#design |design principles]] of service from the previous sections now let's study deeper and more involved subject - "Design pattern associated with service" in this section.

Now Lets study some of the design patterns associated with SOA:-
* '''The Document Processor''': The document processor pattern solves the problem of providing a simple and well-defined contract for a service. A contract as mentioned earlier needs to be granular and very well-defined so that no assumptions about its capabilities need to be made. This can be done by using the OOA/OOD principle of "program to an interface". In a service scenario, this would mean we need to define the contract first. That is to define a XML schema to request and the response message, then based on this schema the implementation needs to be done.

Example:
Suppose assume, we are designing a service which does fetch us public tweets based on the search term specified. According to this pattern we must first specify what input does this service is going to input and similarly w.r.to output.
Input for above example case would be, search term in the form of regular expression.
Output for the example would be list of tweets.
Once input/outputs are Identified, next step would be to define them XML schema.Once the XML schema is done we start off with design/development of service.

 
* '''The idempotent message''': This design pattern solves the generic problem of multiple deliveries of the same request where a single request needs to be sent. This is usually observed in transition based systems. To ensure idem-potency, the service contract should be designed in such a way that a unique identifier should be tagged per request. Although unique identifier for each request is part of the agreement it should not assumed that these numbers will remain unique over time. The identifier should be considered as a unit of work and work should be performed once for each unique identifier. Duplicates can be handled in many ways depending on the system.
Example:

For example consider a "order service", which accepts order requests from service consumers and places an order.If the consumer doesn't get any response for the service requested it thinks that the order request might have been lost, so it tries to re-send the request. The problem here would be the order request is called twice and it has side effects of sending the order twice.One approach to this should be to design a service in idempotent fashion .In the above example the "oder request" service could be split into
# createOrder - it returns unique identifier for each request.
# setOrderDetails - place an order based on the unique id and order details mentioned as part of service request.

The createOrder capability would return an orderId that would then be used when the consumer invokes the setOrderDetails capability. If the createOrder capability is invoked two times instead of one the result would be an extI have taken your APC assignment ra orderId, but since it would have no order details it would not lead to anything being delivered to the customer. If the setOrderDetails is invoked two times it should not matter for either the consumer or the service since the setOrderDetails capability is idempotent.

 
* '''Reservation''': This problem solves the problem of maintaining data consistency for long running transactions. We take an approach of creating tentative operations so that database still remains consistent but still we keep a record of ongoing transactions. These tentative operations can go thorough one of these paths. First one is where it operation is completed as all the required messages are completed and the database is updated. The operation is canceled either implicitly due to inconsistency of data etc, or explicitly by the consumer. These services should have certain amount of service levels(time outs) which are explicitly mentioned in the contract and the third possibility is that the service get aborted due to service level considerations.

 

=='''SOA vs Enterprise Architecture'''==
SOA and Enterprise Architecture are two concepts that people tend to confuse with each other .To clarify it, lets us dicuss some of the differences and commonalities between these concepts .Enterprise Architecture discipline defines and maintains the architecture models, governance and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals. So SOA is one of many ways of implementing the IT part of the enterprise architecture. They are similar because both these concepts strive to closely align IT with business, they share similar planning and strategies. The major differences are EA focuses on defining different business components and SOA focuses on providing business services to help these components interact with each other.
 
Lets summarize some of the highlighting things and close this section
Some of the similarities and differences between SOA and EA:
Similarities:
* Both address similar architectural domains - Business,Applications,Integration and Middleware and so on.
* Both are used in the field of IT business and they align with IT business.
* Both of them work using businness requirements/business objective as input.
* Both SOA and EA need similar planning and strategies to work.

Differences:
To make things more clear lets draw out differences between Service Oriented Architecture and Enterprise architecture in the form of table.

{|cellspacing="0" border="2" style="color:black; background-color:Grey;"
!style="width:25%"|Enterprise Architecture
!style="width:25%"|Service Oriented Architecture
|-
|EA deals with application frameworks and enterprise applications
|SOA's scope is on service modeling only
|-
|EA focuses on defining business components,
|SOA focuses on business services
|-
|EA addresses enterprise integration patterns and when they should be used.
|SOA provides an integration approach based on using services.
|-

|EA deals with enterprise-level infrastructure including servers, databases
|SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
|-
|} 

=='''References'''==
* Bloor, Robin, Judith Hurwitz, Marcia Kaufman, and Fern Halper. Service Oriented Architecture . 2nd ed. Hoboken: For Dummies [Imprint], 2009. Print.
* Juneja, Girish. Service oriented architecture demystified . Hillsboro, Or.: Intel Press, 2007. Print.
* Hariharan, Charanya, and Brian H. Cameron. Enterprise architecture & service oriented architecture . University Park, Pa.: Pennsylvania State University, 2009. Print.

=='''External links'''==
*[http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html "Stefan Tilkov: 10 Principles of SOA." Web log post. InnoQ: Home. Web. 18 Nov. 2010.] [http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html 1].
*[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html "Gartner: SOA Design Patterns." Weblog post. Service Oriented Enterprise. Web. 23 Nov. 2010 ] [http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html 2].
*[http://msdn.microsoft.com/en-us/library/ms954638.aspx Microsoft Corporation, Architecture Strategy, John Evdemon. "Principles of Service Design: Service Patterns and Anti-Patterns." MSDN | Microsoft Development, Subscriptions, Resources, and More. 2005. Web. 23 Nov. 2010.] [http://msdn.microsoft.com/en-us/library/ms954638.aspx 3].
*[http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 IBM, Dr. Mamdouh Ibrahim. "Service-Oriented Architecture and Enterprise Architecture, Part 2: Similarities and Differences." IBM - United States. 21 May 2007.Web. 23 Nov. 2010] [http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 4]
*[http://en.wikipedia.org/wiki/Service-oriented_architectur "Service-oriented Architecture." Wikipedia, the Free Encyclopedia. Web.] [http://en.wikipedia.org/wiki/Service-oriented_architecture.Web. 23 Nov. 2010 5].
*[http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html Douglas .K. Bary. "Service-oriented Architecture (SOA) Definition." Web Services and Service-Oriented Architectures. Web][http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html.Web. 23 Nov. 2010 6].

CSC/ECE 517 Fall 2010/ch6 6j ps

2010-11-27T01:14:50Z

Smkakara: /* Deep dive into the design principles of services */

'''SERVICE ORIENTED ARCHITECTURE'''
=='''Introduction'''==
[http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture] is an architectural approach to creating systems built using autonomous services. SOA brings the emphasis to integration of services and there orchestration to build applications. [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] usually seems like a natural development to all the existing methods to do enterprise wide integration of applications.
Concepts of SOA like services, discovery and late binding etc are from older [http://en.wikipedia.org/wiki/Middleware middle ware] solutions like [http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture CORBA]. The [[#design | design principles of SOA]] too are similar to the previously existing [http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design OOA/OOD ] techniques like encapsulation, abstraction and well defined interfaces.

=='''Need for SOA?'''==
Now we know the definition of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] from the previous section, with just the definition or 2 line statements we can't praise [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] . To praise and know the real power of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA], one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture.

Consider the example of banking system. Say the bank is currently handling credit card division, and it developed a software to handle all its transactions.
This software developed is a collection and interaction of various modules like getuserinformation, checking balance , check credit card history and process
payments and so on. Say at some later point of time,a bank started debit card division and again now to handle all its debit card related functionality
it needs one more software, this software has almost the same functionality as the credit card software, with some differences in functionality.
Now the possible solutions the bank can think of in developing the software for debit card division would be :-
* Take the same code and make changes to it: The problem with this approach is code duplication and maintainability. Say if a bug crops in one of the existing modules we now need to change at 2 places one in credit card software and another in debit card software. If company thinks of developing the debit card software using new programming language, then even code reuse is not possible.
* Object oriented approach of inheriting objects: One might say the bank can use Object oriented approach and derive class and functionalities and so on. Even then we have a problem with this approach, we can't alter the existing credit card software if we had to and even maintainability is problem over here. As discussed previously, if bank thinks of writing new software in a different programming language then this solution gets completely ruled out.
 
This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service. Each service communicates with other services and service consumers using data representation methods like [http://en.wikipedia.org/wiki/XML XML(extensible Markup Language)] as compared to function calls in the conventional programming languages. With this approach we have many advantages:

* Reusable code in the form of services: Code is reused in the form of services.
* Code is easily maintainable: As functionality is offered as a service and it is in a single place. It is also autonomous.
* Support for legacy functions: We can reuse legacy functions by writing wrapper around the functionality and make it interact with other services using XML.
* Platform and language independent services: as services interact with each other through XML so the service and the service consumer need not be in the same programming language.

Without SOA many functionalities needs to be duplicated and we face problems such as consistency,maintainability...
As it can be seen from the diagram below , with SOA all the repeated functionalities are made as a common service and are utilized by the consumers(credit card software and debit card software).
 
[[Image:Soa pics.jpg]]

=='''Technical jargons associated with SOA'''==
Before digging deep into [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] concepts like services ,design patterns associated with [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA ] , we need to understand some basic terminologies used in SOA.

Lets explain this using the above example itself.
# Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
# Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
# Directory services or Broker: - After each service is created it registers itself to directory service so that service can be easily located by the consumer of services. whenever consumer wants to utilize the functionality ,he will enquire the directory service and locate the service.
# Web Services:- web services make up a connection technology. It is a way to connect services together into a service-oriented architecture.
# Basic SOA MODEL:
[[Image:Basic_soa.gif|centre]]
This diagram explains the basic SOA model of publish/find/bind.In this model when a service is written it registers itself(publish) with the broker service , the broker is like a directory of service . Whenever a consumer of service, wants to use the functionality of a service he will enquire the directory and finds the information required to bind with the service.Once bind information is obtained , consumer will bind to the service.

<div id="design">

=='''Design principles of Services in SOA'''==
</div>
Services are the most important part of SOA , so now we will discuss about services and the design principles involved in it.Once we discuss principles of services we will ponder over advance topics in design of services - "Design patterns associated with SOA".
===[http://www.soaprinciples.com Overview of key principles of services]===
* '''Service Loose Coupling''' - According to this principle, services should be designed in such a way that it reduces the dependency of given service on other service.
* '''Service Abstraction''' - service should be like a black box, it should hide the implementation details from the outside world.
* '''Service Re-usability''' - services should be implemented in such a fashion that it should be more reusable.
* '''Service Statelessness''' - service should be implemented in such a fashion that it tries to minimize the amount of state information it stores. It should store the state information if it is really necessary.
* '''Service Discover-ability''' - Each service should be associated with meta data, this allows us to discover the service and what it does, its input requirements.
* '''Service Autonomy''' - For the service to work correctly and reliably it should have some amount of control on its underlying environment.According to this principle only limited autonomy is provided to the service such that it works correctly.

===Deep dive into the design principles of services===

Following are some of the key tenets that needs to be discussed in detail:-
 
*'''Boundaries are explicit''' 
A service's boundary is its interface to the outside world which is published using a [http://en.wikipedia.org/wiki/WSDL WSDL](Web Services Description Language). Principles that needs to be kept in mind while we design SOA systems and which come under this tenet are, ''Services should be easy to consume'' - that is a developer should be able to write software easily by consuming the services. ''The services should be designed keeping evolution in mind''.'' Services built should be granular so that they can be easily reused.
''
*'''Services are autonomous'''
Services are independently designed, implemented, deployed and version-ed. A designer should not make any assumptions about the service and its capabilities
other than what is provided by the contract. For example if a network latency was assumed and if the computer was moved to a new topology then the network
latency can change. Principles under this tenet a service designer should know are, We should be pessimistic about a service and its capabilities other than
the ones mentioned in the WSDL. We should also be pessimistic about the consumer of the services, so a lot error handling and compensation should be provided.
Services should be version-ed independent of the systems that consume them.
 
*'''Services share Schema and Contract, not Class''':
Make sure that a service contract remains stable and use the extensible properties of XML and [http://en.wikipedia.org/wiki/SOAP SOAP](optional headers) to add any exceptions. We are referring to the WSDL when we say contract in the above statement. Version services in case changes are unavoidable there by ensuring compliance to all the consumers.
 
*'''Service compatibility is based on policy''':
WSDL can communicate only syntactically for consuming a service. In many cases this is not good enough, especially to share semantic information about consuming the service. The service designer should use the WS-Policy standards for this and should not try to include this somehow into the [http://en.wikipedia.org/wiki/WSDL WSDL]. For example if the government is providing a service to identify miscreants by image comparison. If there is a compliance required from the consumers end about the size and quality of the photo to be used for comparison this should be taken care of using the WS-Policy requirements.
 
*'''[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling]''':
Coupling is a entity which tells us level of dependency that exists between program modules.Ideally speaking there should be zero coupling between modules.
Based on the level/degree of dependencies between modules we have different types of coupling like Content coupling (high), Data coupling, Message coupling (low) and
so on.Good service in SOA should exhibit low coupling as in message coupling
a)message coupling' - this is one of the loosest forms of coupling where in the calling function doesn't know the location of the recipient and has very less
knowledge of the recipient.
 
*'''[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion]'''
Another important concept that need to be discussed with respect to SOA is cohesion.Cohesion tells us about how the parts/sections in the service are related to
each other.Ideally modules should have very high cohesion.Good service in SOA should exhibit one of the following types of cohesion:
a)Functional Cohesion: Here module does only one thing , such type of services are highly reusable.
b)Sequential Cohesion: module does several tasks and that must be in order.
c)Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

In Summary, service we design should have loose coupling and have high cohesion.

=='''Design Patterns associated with SOA'''==
With the background of general [[#design |design principles]] of service from the previous sections now lets study deeper and more involved subject - "Design pattern associated with service" in this section.

Now Lets study some of the design patterns associated with SOA:-
* '''The Document Processor''': The document processor pattern solves the problem of providing a simple and well-defined contract for a service. A contract as mentioned earlier needs to be granular and very well-defined so that no assumptions about its capabilities need to be made. This can be done by using the OOA/OOD principle of "program to an interface". In a service scenario this would mean define the contract first. That is to define a XML schema to request and the response message, then based on this schema the implementation needs to be done.

Example:
Suppose assume, we are designing a service which does fetch us public tweets based on the search term specified, According to this pattern we must first specify what input does this service is going to input and similarly w.r.to output.
Input for above example case would be, search term in the form of regular expression.
Output for the example would be list of tweets.
Once input/outputs are Identified, next step would be to define them XML schema.Once the XML schema is done we start off with design/development of service.

 
* '''The idempotent message''': This design pattern solves the generic problem of multiple deliveries of the same request where a single request needs to be sent. This is usually observed in transition based systems. To ensure idem-potency, the service contract should be designed in such a way that a unique identifier should be tagged per request. Although unique identifier for each request is part of the agreement it should not assumed that these numbers will remain unique over time. The identifier should be considered as a unit of work and work should be performed once for each unique identifier. Duplicates can be handled in many ways depending on the system.
Example:

For example consider a "order service", which accepts order requests from service consumers and places an order.If the consumer doesn't get any response for the service requested it thinks that the order request might have been lost , so it tries to re-send the request,Problem here would be the order request is called twice and it has side effects of sending the order twice.One approach to this should be design a service in idempotent fashion .In the above example the "oder request" service could be split into
# createOrder - it returns unique identifier for each request.
# setOrderDetails - place an order based on the unique id and order details mentioned as part of service request.

The createOrder capability would return an orderId that would then be used when the consumer invokes the setOrderDetails capability. If the createOrder capability is invoked two times instead of one the result would be an extI have taken your APC assignment ra orderId, but since it would have no order details it would not lead to anything being delivered to the customer. If the setOrderDetails is invoked two times it should not matter for either the consumer or the service since the setOrderDetails capability is idempotent

 
* '''Reservation''': This problem solves the problem of maintaining data consistency for long running transactions. We take an approach of creating tentative operations so that database still remains consistent but still we keep a record of ongoing transactions. These tentative operations can go thorough one of these paths. First one is where it operation is completed as all the required messages are completed and the database is updated. The operation is canceled either implicitly due to inconsistency of data etc, or explicitly by the consumer. These services should have certain amount of service levels(time outs) which are explicitly mentioned in the contract and the third possibility is that the service get aborted due to service level considerations.

 

=='''SOA vs Enterprise Architecture'''==
SOA and Enterprise Architecture are two concepts that people tend to confuse with each other .To clarify it, lets us dicuss some of the differences and commonalities between these concepts .Enterprise Architecture discipline defines and maintains the architecture models, governance and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals. So SOA is one of many ways of implementing the IT part of the enterprise architecture. They are similar because both these concepts strive to closely align IT with business, they share similar planning and strategies. The major differences are EA focuses on defining different business components and SOA focuses on providing business services to help these components interact with each other.
 
Lets summarize some of the highlighting things and close this section
Some of the similarities and differences between SOA and EA:
Similarities:
* Both address similar architectural domains - Business,Applications,Integration and Middleware and so on.
* Both are used in the field of IT business and they align with IT business.
* Both of them work using businness requirements/business objective as input.
* Both SOA and EA need similar planning and strategies to work.

Differences:
To make things more clear lets draw out differences between Service Oriented Architecture and Enterprise architecture in the form of table.

{|cellspacing="0" border="2" style="color:black; background-color:Grey;"
!style="width:25%"|Enterprise Architecture
!style="width:25%"|Service Oriented Architecture
|-
|EA deals with application frameworks and enterprise applications
|SOA's scope is on service modeling only
|-
|EA focuses on defining business components,
|SOA focuses on business services
|-
|EA addresses enterprise integration patterns and when they should be used.
|SOA provides an integration approach based on using services.
|-

|EA deals with enterprise-level infrastructure including servers, databases
|SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
|-
|} 

=='''References'''==
* Bloor, Robin, Judith Hurwitz, Marcia Kaufman, and Fern Halper. Service Oriented Architecture . 2nd ed. Hoboken: For Dummies [Imprint], 2009. Print.
* Juneja, Girish. Service oriented architecture demystified . Hillsboro, Or.: Intel Press, 2007. Print.
* Hariharan, Charanya, and Brian H. Cameron. Enterprise architecture & service oriented architecture . University Park, Pa.: Pennsylvania State University, 2009. Print.

=='''External links'''==
*[http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html "Stefan Tilkov: 10 Principles of SOA." Web log post. InnoQ: Home. Web. 18 Nov. 2010.] [http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html 1].
*[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html "Gartner: SOA Design Patterns." Weblog post. Service Oriented Enterprise. Web. 23 Nov. 2010 ] [http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html 2].
*[http://msdn.microsoft.com/en-us/library/ms954638.aspx Microsoft Corporation, Architecture Strategy, John Evdemon. "Principles of Service Design: Service Patterns and Anti-Patterns." MSDN | Microsoft Development, Subscriptions, Resources, and More. 2005. Web. 23 Nov. 2010.] [http://msdn.microsoft.com/en-us/library/ms954638.aspx 3].
*[http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 IBM, Dr. Mamdouh Ibrahim. "Service-Oriented Architecture and Enterprise Architecture, Part 2: Similarities and Differences." IBM - United States. 21 May 2007.Web. 23 Nov. 2010] [http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 4]
*[http://en.wikipedia.org/wiki/Service-oriented_architectur "Service-oriented Architecture." Wikipedia, the Free Encyclopedia. Web.] [http://en.wikipedia.org/wiki/Service-oriented_architecture.Web. 23 Nov. 2010 5].
*[http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html Douglas .K. Bary. "Service-oriented Architecture (SOA) Definition." Web Services and Service-Oriented Architectures. Web][http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html.Web. 23 Nov. 2010 6].

CSC/ECE 517 Fall 2010/ch6 6j ps

2010-11-27T01:14:19Z

Smkakara: /* Deep dive into the design principles of services */

'''SERVICE ORIENTED ARCHITECTURE'''
=='''Introduction'''==
[http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture] is an architectural approach to creating systems built using autonomous services. SOA brings the emphasis to integration of services and there orchestration to build applications. [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] usually seems like a natural development to all the existing methods to do enterprise wide integration of applications.
Concepts of SOA like services, discovery and late binding etc are from older [http://en.wikipedia.org/wiki/Middleware middle ware] solutions like [http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture CORBA]. The [[#design | design principles of SOA]] too are similar to the previously existing [http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design OOA/OOD ] techniques like encapsulation, abstraction and well defined interfaces.

=='''Need for SOA?'''==
Now we know the definition of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] from the previous section, with just the definition or 2 line statements we can't praise [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] . To praise and know the real power of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA], one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture.

Consider the example of banking system. Say the bank is currently handling credit card division, and it developed a software to handle all its transactions.
This software developed is a collection and interaction of various modules like getuserinformation, checking balance , check credit card history and process
payments and so on. Say at some later point of time,a bank started debit card division and again now to handle all its debit card related functionality
it needs one more software, this software has almost the same functionality as the credit card software, with some differences in functionality.
Now the possible solutions the bank can think of in developing the software for debit card division would be :-
* Take the same code and make changes to it: The problem with this approach is code duplication and maintainability. Say if a bug crops in one of the existing modules we now need to change at 2 places one in credit card software and another in debit card software. If company thinks of developing the debit card software using new programming language, then even code reuse is not possible.
* Object oriented approach of inheriting objects: One might say the bank can use Object oriented approach and derive class and functionalities and so on. Even then we have a problem with this approach, we can't alter the existing credit card software if we had to and even maintainability is problem over here. As discussed previously, if bank thinks of writing new software in a different programming language then this solution gets completely ruled out.
 
This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service. Each service communicates with other services and service consumers using data representation methods like [http://en.wikipedia.org/wiki/XML XML(extensible Markup Language)] as compared to function calls in the conventional programming languages. With this approach we have many advantages:

* Reusable code in the form of services: Code is reused in the form of services.
* Code is easily maintainable: As functionality is offered as a service and it is in a single place. It is also autonomous.
* Support for legacy functions: We can reuse legacy functions by writing wrapper around the functionality and make it interact with other services using XML.
* Platform and language independent services: as services interact with each other through XML so the service and the service consumer need not be in the same programming language.

Without SOA many functionalities needs to be duplicated and we face problems such as consistency,maintainability...
As it can be seen from the diagram below , with SOA all the repeated functionalities are made as a common service and are utilized by the consumers(credit card software and debit card software).
 
[[Image:Soa pics.jpg]]

=='''Technical jargons associated with SOA'''==
Before digging deep into [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] concepts like services ,design patterns associated with [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA ] , we need to understand some basic terminologies used in SOA.

Lets explain this using the above example itself.
# Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
# Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
# Directory services or Broker: - After each service is created it registers itself to directory service so that service can be easily located by the consumer of services. whenever consumer wants to utilize the functionality ,he will enquire the directory service and locate the service.
# Web Services:- web services make up a connection technology. It is a way to connect services together into a service-oriented architecture.
# Basic SOA MODEL:
[[Image:Basic_soa.gif|centre]]
This diagram explains the basic SOA model of publish/find/bind.In this model when a service is written it registers itself(publish) with the broker service , the broker is like a directory of service . Whenever a consumer of service, wants to use the functionality of a service he will enquire the directory and finds the information required to bind with the service.Once bind information is obtained , consumer will bind to the service.

<div id="design">

=='''Design principles of Services in SOA'''==
</div>
Services are the most important part of SOA , so now we will discuss about services and the design principles involved in it.Once we discuss principles of services we will ponder over advance topics in design of services - "Design patterns associated with SOA".
===[http://www.soaprinciples.com Overview of key principles of services]===
* '''Service Loose Coupling''' - According to this principle, services should be designed in such a way that it reduces the dependency of given service on other service.
* '''Service Abstraction''' - service should be like a black box, it should hide the implementation details from the outside world.
* '''Service Re-usability''' - services should be implemented in such a fashion that it should be more reusable.
* '''Service Statelessness''' - service should be implemented in such a fashion that it tries to minimize the amount of state information it stores. It should store the state information if it is really necessary.
* '''Service Discover-ability''' - Each service should be associated with meta data, this allows us to discover the service and what it does, its input requirements.
* '''Service Autonomy''' - For the service to work correctly and reliably it should have some amount of control on its underlying environment.According to this principle only limited autonomy is provided to the service such that it works correctly.

===Deep dive into the design principles of services===

Following are some of the key tenets that needs to be discussed in detail:-
 
*'''Boundaries are explicit''' 
A service's boundary is its interface to the outside world which is published using a [http://en.wikipedia.org/wiki/WSDL WSDL](Web Services Description Language). Principles that needs to be kept in mind while we design SOA systems and which come under this tenet are, ''Services should be easy to consume'' - that is a developer should be able to write software easily by consuming the services. ''The services should be designed keeping evolution in mind''.'' Services built should be granular so that they can be easily reused.
''
*'''Services are autonomous'''
Services are independently designed, implemented, deployed and version-ed. A designer should not make any assumptions about the service and its capabilities
other than what is provided by the contract. For example if a network latency was assumed and if the computer was moved to a new topology then the network
latency can change. Principles under this tenet a service designer should know are, We should be pessimistic about a service and its capabilities other than
the ones mentioned in the WSDL. We should also be pessimistic about the consumer of the services, so a lot error handling and compensation should be provided.
Services should be version-ed independent of the systems that consume them.
 
*'''Services share Schema and Contract, not Class''':
Make sure that a service contract remains stable and use the extensible properties of XML and [http://en.wikipedia.org/wiki/SOAP SOAP](optional headers) to add any exceptions. We are referring to the WSDL when we say contract in the above statement. Version services in case changes are unavoidable there by ensuring compliance to all the consumers.
 
*'''Service compatibility is based on policy''':
WSDL can communicate only syntactically for consuming a service. In many cases this is not good enough, especially to share semantic information about consuming the service. The service designer should use the WS-Policy standards for this and should not try to include this somehow into the [http://en.wikipedia.org/wiki/WSDL WSDL]. For example if the government is providing a service to identify miscreants by image comparison. If there is a compliance required from the consumers end about the size and quality of the photo to be used for comparison this should be taken care of using the WS-Policy requirements.
 
*'''[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling]''':
Coupling is a entity which tells us level of dependency that exists between program modules.Ideally speaking there should be zero coupling between modules.
Based on the level/degree of dependencies between modules we have different types of coupling like Content coupling (high), Data coupling, Message coupling (low) and
so on.Good service in SOA should exhibit low coupling as in message coupling
a)message coupling' - this is one of the loosest forms of coupling where in the calling function doesn't know the location of the recipient and has very less
knowledge of the recipient.
 
*'''[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion]'''
Another important concept that need to be discussed with respect to SOA is cohesion.Cohesion tells us about how the parts/sections in the service are related to
each other.Ideally modules should have very high cohesion.Good service in SOA should exhibit one of the following types of cohesion:
a)Functional Cohesion: Here module does only one thing , such type of services are highly reusable.
b)Sequential Cohesion: module does several tasks and that must be in order.
c)Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

In Summary ,service we design should have loose coupling and have high cohesion.

=='''Design Patterns associated with SOA'''==
With the background of general [[#design |design principles]] of service from the previous sections now lets study deeper and more involved subject - "Design pattern associated with service" in this section.

Now Lets study some of the design patterns associated with SOA:-
* '''The Document Processor''': The document processor pattern solves the problem of providing a simple and well-defined contract for a service. A contract as mentioned earlier needs to be granular and very well-defined so that no assumptions about its capabilities need to be made. This can be done by using the OOA/OOD principle of "program to an interface". In a service scenario this would mean define the contract first. That is to define a XML schema to request and the response message, then based on this schema the implementation needs to be done.

Example:
Suppose assume, we are designing a service which does fetch us public tweets based on the search term specified, According to this pattern we must first specify what input does this service is going to input and similarly w.r.to output.
Input for above example case would be, search term in the form of regular expression.
Output for the example would be list of tweets.
Once input/outputs are Identified, next step would be to define them XML schema.Once the XML schema is done we start off with design/development of service.

 
* '''The idempotent message''': This design pattern solves the generic problem of multiple deliveries of the same request where a single request needs to be sent. This is usually observed in transition based systems. To ensure idem-potency, the service contract should be designed in such a way that a unique identifier should be tagged per request. Although unique identifier for each request is part of the agreement it should not assumed that these numbers will remain unique over time. The identifier should be considered as a unit of work and work should be performed once for each unique identifier. Duplicates can be handled in many ways depending on the system.
Example:

For example consider a "order service", which accepts order requests from service consumers and places an order.If the consumer doesn't get any response for the service requested it thinks that the order request might have been lost , so it tries to re-send the request,Problem here would be the order request is called twice and it has side effects of sending the order twice.One approach to this should be design a service in idempotent fashion .In the above example the "oder request" service could be split into
# createOrder - it returns unique identifier for each request.
# setOrderDetails - place an order based on the unique id and order details mentioned as part of service request.

The createOrder capability would return an orderId that would then be used when the consumer invokes the setOrderDetails capability. If the createOrder capability is invoked two times instead of one the result would be an extI have taken your APC assignment ra orderId, but since it would have no order details it would not lead to anything being delivered to the customer. If the setOrderDetails is invoked two times it should not matter for either the consumer or the service since the setOrderDetails capability is idempotent

 
* '''Reservation''': This problem solves the problem of maintaining data consistency for long running transactions. We take an approach of creating tentative operations so that database still remains consistent but still we keep a record of ongoing transactions. These tentative operations can go thorough one of these paths. First one is where it operation is completed as all the required messages are completed and the database is updated. The operation is canceled either implicitly due to inconsistency of data etc, or explicitly by the consumer. These services should have certain amount of service levels(time outs) which are explicitly mentioned in the contract and the third possibility is that the service get aborted due to service level considerations.

 

=='''SOA vs Enterprise Architecture'''==
SOA and Enterprise Architecture are two concepts that people tend to confuse with each other .To clarify it, lets us dicuss some of the differences and commonalities between these concepts .Enterprise Architecture discipline defines and maintains the architecture models, governance and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals. So SOA is one of many ways of implementing the IT part of the enterprise architecture. They are similar because both these concepts strive to closely align IT with business, they share similar planning and strategies. The major differences are EA focuses on defining different business components and SOA focuses on providing business services to help these components interact with each other.
 
Lets summarize some of the highlighting things and close this section
Some of the similarities and differences between SOA and EA:
Similarities:
* Both address similar architectural domains - Business,Applications,Integration and Middleware and so on.
* Both are used in the field of IT business and they align with IT business.
* Both of them work using businness requirements/business objective as input.
* Both SOA and EA need similar planning and strategies to work.

Differences:
To make things more clear lets draw out differences between Service Oriented Architecture and Enterprise architecture in the form of table.

{|cellspacing="0" border="2" style="color:black; background-color:Grey;"
!style="width:25%"|Enterprise Architecture
!style="width:25%"|Service Oriented Architecture
|-
|EA deals with application frameworks and enterprise applications
|SOA's scope is on service modeling only
|-
|EA focuses on defining business components,
|SOA focuses on business services
|-
|EA addresses enterprise integration patterns and when they should be used.
|SOA provides an integration approach based on using services.
|-

|EA deals with enterprise-level infrastructure including servers, databases
|SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
|-
|} 

=='''References'''==
* Bloor, Robin, Judith Hurwitz, Marcia Kaufman, and Fern Halper. Service Oriented Architecture . 2nd ed. Hoboken: For Dummies [Imprint], 2009. Print.
* Juneja, Girish. Service oriented architecture demystified . Hillsboro, Or.: Intel Press, 2007. Print.
* Hariharan, Charanya, and Brian H. Cameron. Enterprise architecture & service oriented architecture . University Park, Pa.: Pennsylvania State University, 2009. Print.

=='''External links'''==
*[http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html "Stefan Tilkov: 10 Principles of SOA." Web log post. InnoQ: Home. Web. 18 Nov. 2010.] [http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html 1].
*[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html "Gartner: SOA Design Patterns." Weblog post. Service Oriented Enterprise. Web. 23 Nov. 2010 ] [http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html 2].
*[http://msdn.microsoft.com/en-us/library/ms954638.aspx Microsoft Corporation, Architecture Strategy, John Evdemon. "Principles of Service Design: Service Patterns and Anti-Patterns." MSDN | Microsoft Development, Subscriptions, Resources, and More. 2005. Web. 23 Nov. 2010.] [http://msdn.microsoft.com/en-us/library/ms954638.aspx 3].
*[http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 IBM, Dr. Mamdouh Ibrahim. "Service-Oriented Architecture and Enterprise Architecture, Part 2: Similarities and Differences." IBM - United States. 21 May 2007.Web. 23 Nov. 2010] [http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 4]
*[http://en.wikipedia.org/wiki/Service-oriented_architectur "Service-oriented Architecture." Wikipedia, the Free Encyclopedia. Web.] [http://en.wikipedia.org/wiki/Service-oriented_architecture.Web. 23 Nov. 2010 5].
*[http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html Douglas .K. Bary. "Service-oriented Architecture (SOA) Definition." Web Services and Service-Oriented Architectures. Web][http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html.Web. 23 Nov. 2010 6].

CSC/ECE 517 Fall 2010/ch6 6j ps

2010-11-27T01:07:58Z

Smkakara: /* [http://www.soaprinciples.com Overview of key principles of services] */

'''SERVICE ORIENTED ARCHITECTURE'''
=='''Introduction'''==
[http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture] is an architectural approach to creating systems built using autonomous services. SOA brings the emphasis to integration of services and there orchestration to build applications. [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] usually seems like a natural development to all the existing methods to do enterprise wide integration of applications.
Concepts of SOA like services, discovery and late binding etc are from older [http://en.wikipedia.org/wiki/Middleware middle ware] solutions like [http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture CORBA]. The [[#design | design principles of SOA]] too are similar to the previously existing [http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design OOA/OOD ] techniques like encapsulation, abstraction and well defined interfaces.

=='''Need for SOA?'''==
Now we know the definition of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] from the previous section, with just the definition or 2 line statements we can't praise [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] . To praise and know the real power of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA], one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture.

Consider the example of banking system. Say the bank is currently handling credit card division, and it developed a software to handle all its transactions.
This software developed is a collection and interaction of various modules like getuserinformation, checking balance , check credit card history and process
payments and so on. Say at some later point of time,a bank started debit card division and again now to handle all its debit card related functionality
it needs one more software, this software has almost the same functionality as the credit card software, with some differences in functionality.
Now the possible solutions the bank can think of in developing the software for debit card division would be :-
* Take the same code and make changes to it: The problem with this approach is code duplication and maintainability. Say if a bug crops in one of the existing modules we now need to change at 2 places one in credit card software and another in debit card software. If company thinks of developing the debit card software using new programming language, then even code reuse is not possible.
* Object oriented approach of inheriting objects: One might say the bank can use Object oriented approach and derive class and functionalities and so on. Even then we have a problem with this approach, we can't alter the existing credit card software if we had to and even maintainability is problem over here. As discussed previously, if bank thinks of writing new software in a different programming language then this solution gets completely ruled out.
 
This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service. Each service communicates with other services and service consumers using data representation methods like [http://en.wikipedia.org/wiki/XML XML(extensible Markup Language)] as compared to function calls in the conventional programming languages. With this approach we have many advantages:

* Reusable code in the form of services: Code is reused in the form of services.
* Code is easily maintainable: As functionality is offered as a service and it is in a single place. It is also autonomous.
* Support for legacy functions: We can reuse legacy functions by writing wrapper around the functionality and make it interact with other services using XML.
* Platform and language independent services: as services interact with each other through XML so the service and the service consumer need not be in the same programming language.

Without SOA many functionalities needs to be duplicated and we face problems such as consistency,maintainability...
As it can be seen from the diagram below , with SOA all the repeated functionalities are made as a common service and are utilized by the consumers(credit card software and debit card software).
 
[[Image:Soa pics.jpg]]

=='''Technical jargons associated with SOA'''==
Before digging deep into [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] concepts like services ,design patterns associated with [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA ] , we need to understand some basic terminologies used in SOA.

Lets explain this using the above example itself.
# Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
# Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
# Directory services or Broker: - After each service is created it registers itself to directory service so that service can be easily located by the consumer of services. whenever consumer wants to utilize the functionality ,he will enquire the directory service and locate the service.
# Web Services:- web services make up a connection technology. It is a way to connect services together into a service-oriented architecture.
# Basic SOA MODEL:
[[Image:Basic_soa.gif|centre]]
This diagram explains the basic SOA model of publish/find/bind.In this model when a service is written it registers itself(publish) with the broker service , the broker is like a directory of service . Whenever a consumer of service, wants to use the functionality of a service he will enquire the directory and finds the information required to bind with the service.Once bind information is obtained , consumer will bind to the service.

<div id="design">

=='''Design principles of Services in SOA'''==
</div>
Services are the most important part of SOA , so now we will discuss about services and the design principles involved in it.Once we discuss principles of services we will ponder over advance topics in design of services - "Design patterns associated with SOA".
===[http://www.soaprinciples.com Overview of key principles of services]===
* '''Service Loose Coupling''' - According to this principle, services should be designed in such a way that it reduces the dependency of given service on other service.
* '''Service Abstraction''' - service should be like a black box, it should hide the implementation details from the outside world.
* '''Service Re-usability''' - services should be implemented in such a fashion that it should be more reusable.
* '''Service Statelessness''' - service should be implemented in such a fashion that it tries to minimize the amount of state information it stores. It should store the state information if it is really necessary.
* '''Service Discover-ability''' - Each service should be associated with meta data, this allows us to discover the service and what it does, its input requirements.
* '''Service Autonomy''' - For the service to work correctly and reliably it should have some amount of control on its underlying environment.According to this principle only limited autonomy is provided to the service such that it works correctly.

===Deep dive into the design principles of services===

Following are some of the key tenets that needs to be discussed in detail:-
 
*'''Boundaries are Explicit''' 
A service's boundary is its interface to the outside world which is published using a [http://en.wikipedia.org/wiki/WSDL WSDL](Web Services Description Language). Principles that needs to be kept in mind while we design SOA systems and which come under this tenet are, ''Services should be easy to consume'' - that is a developer should be able to write software easily by consuming the services. ''The services should be designed keeping evolution in mind''.'' Services built should be granular so that they can be easily reused.
''
*'''Services are autonomous'''
Services are independently designed, implemented, deployed and version-ed. A designer should not make any assumptions about the service and its capabilities
other than what is provided by the contract. For example if a network latency was assumed and if the computer was moved to a new topology then the network
latency can change. Principles under this tenet a service designer should know are, We should be pessimistic about a service and its capabilities other than
the ones mentioned in the WSDL. We should also be pessimistic about the consumer of the services, so a lot error handling and compensation should be provided.
Services should be version-ed independent of the systems that consume them.
 
*'''Services Share Schema and Contract, Not Class''':
Make sure that a service contract remains stable and use the extensible properties of XML and [http://en.wikipedia.org/wiki/SOAP SOAP](optional headers) to add any exceptions. We are referring to the WSDL when we say contract in the above statement. Version services in case changes are unavoidable there by ensuring compliance to all the consumers.
 
*'''Service compatibility is based on policy''':
WSDL can communicate only syntactically for consuming a service. In many cases this is not good enough, especially to share semantic information about consuming the service. The service designer should use the WS-Policy standards for this and should not try to include this somehow into the [http://en.wikipedia.org/wiki/WSDL WSDL]. For example if the government is providing a service to identify miscreants by image comparison. If there is a compliance required from the consumers end about the size and quality of the photo to be used for comparison this should be taken care of using the WS-Policy requirements.
 
*'''[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling]''':
Coupling is a entity which tells us level of dependency that exists between program modules.Ideally speaking there should be zero coupling between modules.
Based on the level/degree of dependencies between modules we have different types of coupling like Content coupling (high), Data coupling, Message coupling (low) and
so on.Good service in SOA should exhibit low coupling as in message coupling
a)message coupling' - this is one of the loosest forms of coupling where in the calling function doesn't know the location of the recipient and has very less
knowledge of the recipient.
 
*'''[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion]'''
Another important concept that need to be discussed with respect to SOA is cohesion.Cohesion tells us about how the parts/sections in the service are related to
each other.Ideally modules should have very cohesion.Good service in SOA should exhibit one of the following types of cohesion:
a)Functional Cohesion: Here module does only one thing , such type of services are highly reusable.
b)Sequential Cohesion: module does several tasks and that must be in order.
c)Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

In Summary ,service we design should have loose coupling and have high cohesion.

=='''Design Patterns associated with SOA'''==
With the background of general [[#design |design principles]] of service from the previous sections now lets study deeper and more involved subject - "Design pattern associated with service" in this section.

Now Lets study some of the design patterns associated with SOA:-
* '''The Document Processor''': The document processor pattern solves the problem of providing a simple and well-defined contract for a service. A contract as mentioned earlier needs to be granular and very well-defined so that no assumptions about its capabilities need to be made. This can be done by using the OOA/OOD principle of "program to an interface". In a service scenario this would mean define the contract first. That is to define a XML schema to request and the response message, then based on this schema the implementation needs to be done.

Example:
Suppose assume, we are designing a service which does fetch us public tweets based on the search term specified, According to this pattern we must first specify what input does this service is going to input and similarly w.r.to output.
Input for above example case would be, search term in the form of regular expression.
Output for the example would be list of tweets.
Once input/outputs are Identified, next step would be to define them XML schema.Once the XML schema is done we start off with design/development of service.

 
* '''The idempotent message''': This design pattern solves the generic problem of multiple deliveries of the same request where a single request needs to be sent. This is usually observed in transition based systems. To ensure idem-potency, the service contract should be designed in such a way that a unique identifier should be tagged per request. Although unique identifier for each request is part of the agreement it should not assumed that these numbers will remain unique over time. The identifier should be considered as a unit of work and work should be performed once for each unique identifier. Duplicates can be handled in many ways depending on the system.
Example:

For example consider a "order service", which accepts order requests from service consumers and places an order.If the consumer doesn't get any response for the service requested it thinks that the order request might have been lost , so it tries to re-send the request,Problem here would be the order request is called twice and it has side effects of sending the order twice.One approach to this should be design a service in idempotent fashion .In the above example the "oder request" service could be split into
# createOrder - it returns unique identifier for each request.
# setOrderDetails - place an order based on the unique id and order details mentioned as part of service request.

The createOrder capability would return an orderId that would then be used when the consumer invokes the setOrderDetails capability. If the createOrder capability is invoked two times instead of one the result would be an extI have taken your APC assignment ra orderId, but since it would have no order details it would not lead to anything being delivered to the customer. If the setOrderDetails is invoked two times it should not matter for either the consumer or the service since the setOrderDetails capability is idempotent

 
* '''Reservation''': This problem solves the problem of maintaining data consistency for long running transactions. We take an approach of creating tentative operations so that database still remains consistent but still we keep a record of ongoing transactions. These tentative operations can go thorough one of these paths. First one is where it operation is completed as all the required messages are completed and the database is updated. The operation is canceled either implicitly due to inconsistency of data etc, or explicitly by the consumer. These services should have certain amount of service levels(time outs) which are explicitly mentioned in the contract and the third possibility is that the service get aborted due to service level considerations.

 

=='''SOA vs Enterprise Architecture'''==
SOA and Enterprise Architecture are two concepts that people tend to confuse with each other .To clarify it, lets us dicuss some of the differences and commonalities between these concepts .Enterprise Architecture discipline defines and maintains the architecture models, governance and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals. So SOA is one of many ways of implementing the IT part of the enterprise architecture. They are similar because both these concepts strive to closely align IT with business, they share similar planning and strategies. The major differences are EA focuses on defining different business components and SOA focuses on providing business services to help these components interact with each other.
 
Lets summarize some of the highlighting things and close this section
Some of the similarities and differences between SOA and EA:
Similarities:
* Both address similar architectural domains - Business,Applications,Integration and Middleware and so on.
* Both are used in the field of IT business and they align with IT business.
* Both of them work using businness requirements/business objective as input.
* Both SOA and EA need similar planning and strategies to work.

Differences:
To make things more clear lets draw out differences between Service Oriented Architecture and Enterprise architecture in the form of table.

{|cellspacing="0" border="2" style="color:black; background-color:Grey;"
!style="width:25%"|Enterprise Architecture
!style="width:25%"|Service Oriented Architecture
|-
|EA deals with application frameworks and enterprise applications
|SOA's scope is on service modeling only
|-
|EA focuses on defining business components,
|SOA focuses on business services
|-
|EA addresses enterprise integration patterns and when they should be used.
|SOA provides an integration approach based on using services.
|-

|EA deals with enterprise-level infrastructure including servers, databases
|SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
|-
|} 

=='''References'''==
* Bloor, Robin, Judith Hurwitz, Marcia Kaufman, and Fern Halper. Service Oriented Architecture . 2nd ed. Hoboken: For Dummies [Imprint], 2009. Print.
* Juneja, Girish. Service oriented architecture demystified . Hillsboro, Or.: Intel Press, 2007. Print.
* Hariharan, Charanya, and Brian H. Cameron. Enterprise architecture & service oriented architecture . University Park, Pa.: Pennsylvania State University, 2009. Print.

=='''External links'''==
*[http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html "Stefan Tilkov: 10 Principles of SOA." Web log post. InnoQ: Home. Web. 18 Nov. 2010.] [http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html 1].
*[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html "Gartner: SOA Design Patterns." Weblog post. Service Oriented Enterprise. Web. 23 Nov. 2010 ] [http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html 2].
*[http://msdn.microsoft.com/en-us/library/ms954638.aspx Microsoft Corporation, Architecture Strategy, John Evdemon. "Principles of Service Design: Service Patterns and Anti-Patterns." MSDN | Microsoft Development, Subscriptions, Resources, and More. 2005. Web. 23 Nov. 2010.] [http://msdn.microsoft.com/en-us/library/ms954638.aspx 3].
*[http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 IBM, Dr. Mamdouh Ibrahim. "Service-Oriented Architecture and Enterprise Architecture, Part 2: Similarities and Differences." IBM - United States. 21 May 2007.Web. 23 Nov. 2010] [http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 4]
*[http://en.wikipedia.org/wiki/Service-oriented_architectur "Service-oriented Architecture." Wikipedia, the Free Encyclopedia. Web.] [http://en.wikipedia.org/wiki/Service-oriented_architecture.Web. 23 Nov. 2010 5].
*[http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html Douglas .K. Bary. "Service-oriented Architecture (SOA) Definition." Web Services and Service-Oriented Architectures. Web][http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html.Web. 23 Nov. 2010 6].

CSC/ECE 517 Fall 2010/ch6 6j ps

2010-11-27T00:58:12Z

Smkakara: /* '''Need for SOA?''' */

'''SERVICE ORIENTED ARCHITECTURE'''
=='''Introduction'''==
[http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture] is an architectural approach to creating systems built using autonomous services. SOA brings the emphasis to integration of services and there orchestration to build applications. [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] usually seems like a natural development to all the existing methods to do enterprise wide integration of applications.
Concepts of SOA like services, discovery and late binding etc are from older [http://en.wikipedia.org/wiki/Middleware middle ware] solutions like [http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture CORBA]. The [[#design | design principles of SOA]] too are similar to the previously existing [http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design OOA/OOD ] techniques like encapsulation, abstraction and well defined interfaces.

=='''Need for SOA?'''==
Now we know the definition of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] from the previous section, with just the definition or 2 line statements we can't praise [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] . To praise and know the real power of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA], one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture.

Consider the example of banking system. Say the bank is currently handling credit card division, and it developed a software to handle all its transactions.
This software developed is a collection and interaction of various modules like getuserinformation, checking balance , check credit card history and process
payments and so on. Say at some later point of time,a bank started debit card division and again now to handle all its debit card related functionality
it needs one more software, this software has almost the same functionality as the credit card software, with some differences in functionality.
Now the possible solutions the bank can think of in developing the software for debit card division would be :-
* Take the same code and make changes to it: The problem with this approach is code duplication and maintainability. Say if a bug crops in one of the existing modules we now need to change at 2 places one in credit card software and another in debit card software. If company thinks of developing the debit card software using new programming language, then even code reuse is not possible.
* Object oriented approach of inheriting objects: One might say the bank can use Object oriented approach and derive class and functionalities and so on. Even then we have a problem with this approach, we can't alter the existing credit card software if we had to and even maintainability is problem over here. As discussed previously, if bank thinks of writing new software in a different programming language then this solution gets completely ruled out.
 
This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service. Each service communicates with other services and service consumers using data representation methods like [http://en.wikipedia.org/wiki/XML XML(extensible Markup Language)] as compared to function calls in the conventional programming languages. With this approach we have many advantages:

* Reusable code in the form of services: Code is reused in the form of services.
* Code is easily maintainable: As functionality is offered as a service and it is in a single place. It is also autonomous.
* Support for legacy functions: We can reuse legacy functions by writing wrapper around the functionality and make it interact with other services using XML.
* Platform and language independent services: as services interact with each other through XML so the service and the service consumer need not be in the same programming language.

Without SOA many functionalities needs to be duplicated and we face problems such as consistency,maintainability...
As it can be seen from the diagram below , with SOA all the repeated functionalities are made as a common service and are utilized by the consumers(credit card software and debit card software).
 
[[Image:Soa pics.jpg]]

=='''Technical jargons associated with SOA'''==
Before digging deep into [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] concepts like services ,design patterns associated with [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA ] , we need to understand some basic terminologies used in SOA.

Lets explain this using the above example itself.
# Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
# Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
# Directory services or Broker: - After each service is created it registers itself to directory service so that service can be easily located by the consumer of services. whenever consumer wants to utilize the functionality ,he will enquire the directory service and locate the service.
# Web Services:- web services make up a connection technology. It is a way to connect services together into a service-oriented architecture.
# Basic SOA MODEL:
[[Image:Basic_soa.gif|centre]]
This diagram explains the basic SOA model of publish/find/bind.In this model when a service is written it registers itself(publish) with the broker service , the broker is like a directory of service . Whenever a consumer of service, wants to use the functionality of a service he will enquire the directory and finds the information required to bind with the service.Once bind information is obtained , consumer will bind to the service.

<div id="design">

=='''Design principles of Services in SOA'''==
</div>
Services are the most important part of SOA , so now we will discuss about services and the design principles involved in it.Once we discuss principles of services we will ponder over advance topics in design of services - "Design patterns associated with SOA".
===[http://www.soaprinciples.com Overview of key principles of services]===
* '''Service Loose Coupling''' - According to this principle service should be designed in such a way that it reduces the dependency of given service on other service.
* '''Service Abstraction''' - service should be like a black box, it should hide the implementation details from the outside world.
* '''Service Re-usability''' - services should be implemented in such a fashion that it should be more reusable.
* '''Service Statelessness''' - Service should be implemented in such a fashion that it tries to minimize the amount of state information it stores. It should store the state information if its really necessary.
* '''Service Discover-ability''' - Each service should be associated with meta data, this allows us to discover the service and what it does, its input requirements.
* '''Service Autonomy''' - For the service to work correctly and reliably it should have some amount of control on its underlying environment.According to this principle only limited autonomy is provided to the service such that it works correctly.

===Deep dive into the design principles of services===

Following are some of the key tenets that needs to be discussed in detail:-
 
*'''Boundaries are Explicit''' 
A service's boundary is its interface to the outside world which is published using a [http://en.wikipedia.org/wiki/WSDL WSDL](Web Services Description Language). Principles that needs to be kept in mind while we design SOA systems and which come under this tenet are, ''Services should be easy to consume'' - that is a developer should be able to write software easily by consuming the services. ''The services should be designed keeping evolution in mind''.'' Services built should be granular so that they can be easily reused.
''
*'''Services are autonomous'''
Services are independently designed, implemented, deployed and version-ed. A designer should not make any assumptions about the service and its capabilities
other than what is provided by the contract. For example if a network latency was assumed and if the computer was moved to a new topology then the network
latency can change. Principles under this tenet a service designer should know are, We should be pessimistic about a service and its capabilities other than
the ones mentioned in the WSDL. We should also be pessimistic about the consumer of the services, so a lot error handling and compensation should be provided.
Services should be version-ed independent of the systems that consume them.
 
*'''Services Share Schema and Contract, Not Class''':
Make sure that a service contract remains stable and use the extensible properties of XML and [http://en.wikipedia.org/wiki/SOAP SOAP](optional headers) to add any exceptions. We are referring to the WSDL when we say contract in the above statement. Version services in case changes are unavoidable there by ensuring compliance to all the consumers.
 
*'''Service compatibility is based on policy''':
WSDL can communicate only syntactically for consuming a service. In many cases this is not good enough, especially to share semantic information about consuming the service. The service designer should use the WS-Policy standards for this and should not try to include this somehow into the [http://en.wikipedia.org/wiki/WSDL WSDL]. For example if the government is providing a service to identify miscreants by image comparison. If there is a compliance required from the consumers end about the size and quality of the photo to be used for comparison this should be taken care of using the WS-Policy requirements.
 
*'''[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling]''':
Coupling is a entity which tells us level of dependency that exists between program modules.Ideally speaking there should be zero coupling between modules.
Based on the level/degree of dependencies between modules we have different types of coupling like Content coupling (high), Data coupling, Message coupling (low) and
so on.Good service in SOA should exhibit low coupling as in message coupling
a)message coupling' - this is one of the loosest forms of coupling where in the calling function doesn't know the location of the recipient and has very less
knowledge of the recipient.
 
*'''[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion]'''
Another important concept that need to be discussed with respect to SOA is cohesion.Cohesion tells us about how the parts/sections in the service are related to
each other.Ideally modules should have very cohesion.Good service in SOA should exhibit one of the following types of cohesion:
a)Functional Cohesion: Here module does only one thing , such type of services are highly reusable.
b)Sequential Cohesion: module does several tasks and that must be in order.
c)Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

In Summary ,service we design should have loose coupling and have high cohesion.

=='''Design Patterns associated with SOA'''==
With the background of general [[#design |design principles]] of service from the previous sections now lets study deeper and more involved subject - "Design pattern associated with service" in this section.

Now Lets study some of the design patterns associated with SOA:-
* '''The Document Processor''': The document processor pattern solves the problem of providing a simple and well-defined contract for a service. A contract as mentioned earlier needs to be granular and very well-defined so that no assumptions about its capabilities need to be made. This can be done by using the OOA/OOD principle of "program to an interface". In a service scenario this would mean define the contract first. That is to define a XML schema to request and the response message, then based on this schema the implementation needs to be done.

Example:
Suppose assume, we are designing a service which does fetch us public tweets based on the search term specified, According to this pattern we must first specify what input does this service is going to input and similarly w.r.to output.
Input for above example case would be, search term in the form of regular expression.
Output for the example would be list of tweets.
Once input/outputs are Identified, next step would be to define them XML schema.Once the XML schema is done we start off with design/development of service.

 
* '''The idempotent message''': This design pattern solves the generic problem of multiple deliveries of the same request where a single request needs to be sent. This is usually observed in transition based systems. To ensure idem-potency, the service contract should be designed in such a way that a unique identifier should be tagged per request. Although unique identifier for each request is part of the agreement it should not assumed that these numbers will remain unique over time. The identifier should be considered as a unit of work and work should be performed once for each unique identifier. Duplicates can be handled in many ways depending on the system.
Example:

For example consider a "order service", which accepts order requests from service consumers and places an order.If the consumer doesn't get any response for the service requested it thinks that the order request might have been lost , so it tries to re-send the request,Problem here would be the order request is called twice and it has side effects of sending the order twice.One approach to this should be design a service in idempotent fashion .In the above example the "oder request" service could be split into
# createOrder - it returns unique identifier for each request.
# setOrderDetails - place an order based on the unique id and order details mentioned as part of service request.

The createOrder capability would return an orderId that would then be used when the consumer invokes the setOrderDetails capability. If the createOrder capability is invoked two times instead of one the result would be an extI have taken your APC assignment ra orderId, but since it would have no order details it would not lead to anything being delivered to the customer. If the setOrderDetails is invoked two times it should not matter for either the consumer or the service since the setOrderDetails capability is idempotent

 
* '''Reservation''': This problem solves the problem of maintaining data consistency for long running transactions. We take an approach of creating tentative operations so that database still remains consistent but still we keep a record of ongoing transactions. These tentative operations can go thorough one of these paths. First one is where it operation is completed as all the required messages are completed and the database is updated. The operation is canceled either implicitly due to inconsistency of data etc, or explicitly by the consumer. These services should have certain amount of service levels(time outs) which are explicitly mentioned in the contract and the third possibility is that the service get aborted due to service level considerations.

 

=='''SOA vs Enterprise Architecture'''==
SOA and Enterprise Architecture are two concepts that people tend to confuse with each other .To clarify it, lets us dicuss some of the differences and commonalities between these concepts .Enterprise Architecture discipline defines and maintains the architecture models, governance and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals. So SOA is one of many ways of implementing the IT part of the enterprise architecture. They are similar because both these concepts strive to closely align IT with business, they share similar planning and strategies. The major differences are EA focuses on defining different business components and SOA focuses on providing business services to help these components interact with each other.
 
Lets summarize some of the highlighting things and close this section
Some of the similarities and differences between SOA and EA:
Similarities:
* Both address similar architectural domains - Business,Applications,Integration and Middleware and so on.
* Both are used in the field of IT business and they align with IT business.
* Both of them work using businness requirements/business objective as input.
* Both SOA and EA need similar planning and strategies to work.

Differences:
To make things more clear lets draw out differences between Service Oriented Architecture and Enterprise architecture in the form of table.

{|cellspacing="0" border="2" style="color:black; background-color:Grey;"
!style="width:25%"|Enterprise Architecture
!style="width:25%"|Service Oriented Architecture
|-
|EA deals with application frameworks and enterprise applications
|SOA's scope is on service modeling only
|-
|EA focuses on defining business components,
|SOA focuses on business services
|-
|EA addresses enterprise integration patterns and when they should be used.
|SOA provides an integration approach based on using services.
|-

|EA deals with enterprise-level infrastructure including servers, databases
|SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
|-
|} 

=='''References'''==
* Bloor, Robin, Judith Hurwitz, Marcia Kaufman, and Fern Halper. Service Oriented Architecture . 2nd ed. Hoboken: For Dummies [Imprint], 2009. Print.
* Juneja, Girish. Service oriented architecture demystified . Hillsboro, Or.: Intel Press, 2007. Print.
* Hariharan, Charanya, and Brian H. Cameron. Enterprise architecture & service oriented architecture . University Park, Pa.: Pennsylvania State University, 2009. Print.

=='''External links'''==
*[http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html "Stefan Tilkov: 10 Principles of SOA." Web log post. InnoQ: Home. Web. 18 Nov. 2010.] [http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html 1].
*[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html "Gartner: SOA Design Patterns." Weblog post. Service Oriented Enterprise. Web. 23 Nov. 2010 ] [http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html 2].
*[http://msdn.microsoft.com/en-us/library/ms954638.aspx Microsoft Corporation, Architecture Strategy, John Evdemon. "Principles of Service Design: Service Patterns and Anti-Patterns." MSDN | Microsoft Development, Subscriptions, Resources, and More. 2005. Web. 23 Nov. 2010.] [http://msdn.microsoft.com/en-us/library/ms954638.aspx 3].
*[http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 IBM, Dr. Mamdouh Ibrahim. "Service-Oriented Architecture and Enterprise Architecture, Part 2: Similarities and Differences." IBM - United States. 21 May 2007.Web. 23 Nov. 2010] [http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 4]
*[http://en.wikipedia.org/wiki/Service-oriented_architectur "Service-oriented Architecture." Wikipedia, the Free Encyclopedia. Web.] [http://en.wikipedia.org/wiki/Service-oriented_architecture.Web. 23 Nov. 2010 5].
*[http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html Douglas .K. Bary. "Service-oriented Architecture (SOA) Definition." Web Services and Service-Oriented Architectures. Web][http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html.Web. 23 Nov. 2010 6].

CSC/ECE 517 Fall 2010/ch6 6j ps

2010-11-27T00:55:06Z

Smkakara: /* '''Need for SOA??''' */

'''SERVICE ORIENTED ARCHITECTURE'''
=='''Introduction'''==
[http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture] is an architectural approach to creating systems built using autonomous services. SOA brings the emphasis to integration of services and there orchestration to build applications. [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] usually seems like a natural development to all the existing methods to do enterprise wide integration of applications.
Concepts of SOA like services, discovery and late binding etc are from older [http://en.wikipedia.org/wiki/Middleware middle ware] solutions like [http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture CORBA]. The [[#design | design principles of SOA]] too are similar to the previously existing [http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design OOA/OOD ] techniques like encapsulation, abstraction and well defined interfaces.

=='''Need for SOA?'''==
Now we know the definition of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] from the previous section, with just the definition or 2 line statements we can't praise [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] . To praise and know the real power of [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA], one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture.

Consider the example of banking system. Say the bank is currently handling credit card division, and it developed a software to handle all its transactions.
This software developed is a collection and interaction of various modules like getuserinformation, checking balance , check credit card history and process
payments and so on. Say at some later point of time,a bank started debit card division and again now to handle all its debit card related functionality
it needs one more software, this software has almost the same functionality as the credit card software, with some differences in functionality.
Now the possible solutions the bank can think of in developing the software for debit card division would be :-
* Take the same code and make changes to it: The problem with this approach is code duplication and maintainability. Say if a bug crops in one of the existing modules we now need to change at 2 places one in credit card software and another in debit card software. If company thinks of developing the debit card software using new programming language, then even code reuse is not possible.
* Object oriented approach of inheriting objects: One might say the bank can use Object oriented approach and derive class and functionalities and so on. Even then we have a problem with this approach, we can't alter the existing credit card software if we had to and even maintainability is problem over here. As discussed previously, if bank thinks of writing new software in a different programming language then this solution gets completely ruled out.
 
This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service. Each service communicates with other services and service consumers using data representation methods like [http://en.wikipedia.org/wiki/XML XML(extensible Markup Language)] as compared to function calls in the conventional programming languages. With this approach we have many advantages:

* Reusable code in the form of services: Code is reused in the form of services.
* Code is easily maintainable: As functionality is offered as a service and it is in a single place. It is also autonomous.
* Support for legacy functions: We can reuse legacy functions by writing wrapper around the functionality and make it interact with other services using XML.
* Platform and language independent services: as services interact with each other through XML so the service and the service consumer need not be in the same programming language.

Without SOA many functionalities needs to be duplicated and we face problems such as consistency,maintainability...
As it can seen from the diagram below , with SOA all the repeated functionalities are made as a common service and are utilized by the consumers(credit card software and debit card software).
 
[[Image:Soa pics.jpg]]

=='''Technical jargons associated with SOA'''==
Before digging deep into [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] concepts like services ,design patterns associated with [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA ] , we need to understand some basic terminologies used in SOA.

Lets explain this using the above example itself.
# Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
# Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
# Directory services or Broker: - After each service is created it registers itself to directory service so that service can be easily located by the consumer of services. whenever consumer wants to utilize the functionality ,he will enquire the directory service and locate the service.
# Web Services:- web services make up a connection technology. It is a way to connect services together into a service-oriented architecture.
# Basic SOA MODEL:
[[Image:Basic_soa.gif|centre]]
This diagram explains the basic SOA model of publish/find/bind.In this model when a service is written it registers itself(publish) with the broker service , the broker is like a directory of service . Whenever a consumer of service, wants to use the functionality of a service he will enquire the directory and finds the information required to bind with the service.Once bind information is obtained , consumer will bind to the service.

<div id="design">

=='''Design principles of Services in SOA'''==
</div>
Services are the most important part of SOA , so now we will discuss about services and the design principles involved in it.Once we discuss principles of services we will ponder over advance topics in design of services - "Design patterns associated with SOA".
===[http://www.soaprinciples.com Overview of key principles of services]===
* '''Service Loose Coupling''' - According to this principle service should be designed in such a way that it reduces the dependency of given service on other service.
* '''Service Abstraction''' - service should be like a black box, it should hide the implementation details from the outside world.
* '''Service Re-usability''' - services should be implemented in such a fashion that it should be more reusable.
* '''Service Statelessness''' - Service should be implemented in such a fashion that it tries to minimize the amount of state information it stores. It should store the state information if its really necessary.
* '''Service Discover-ability''' - Each service should be associated with meta data, this allows us to discover the service and what it does, its input requirements.
* '''Service Autonomy''' - For the service to work correctly and reliably it should have some amount of control on its underlying environment.According to this principle only limited autonomy is provided to the service such that it works correctly.

===Deep dive into the design principles of services===

Following are some of the key tenets that needs to be discussed in detail:-
 
*'''Boundaries are Explicit''' 
A service's boundary is its interface to the outside world which is published using a [http://en.wikipedia.org/wiki/WSDL WSDL](Web Services Description Language). Principles that needs to be kept in mind while we design SOA systems and which come under this tenet are, ''Services should be easy to consume'' - that is a developer should be able to write software easily by consuming the services. ''The services should be designed keeping evolution in mind''.'' Services built should be granular so that they can be easily reused.
''
*'''Services are autonomous'''
Services are independently designed, implemented, deployed and version-ed. A designer should not make any assumptions about the service and its capabilities
other than what is provided by the contract. For example if a network latency was assumed and if the computer was moved to a new topology then the network
latency can change. Principles under this tenet a service designer should know are, We should be pessimistic about a service and its capabilities other than
the ones mentioned in the WSDL. We should also be pessimistic about the consumer of the services, so a lot error handling and compensation should be provided.
Services should be version-ed independent of the systems that consume them.
 
*'''Services Share Schema and Contract, Not Class''':
Make sure that a service contract remains stable and use the extensible properties of XML and [http://en.wikipedia.org/wiki/SOAP SOAP](optional headers) to add any exceptions. We are referring to the WSDL when we say contract in the above statement. Version services in case changes are unavoidable there by ensuring compliance to all the consumers.
 
*'''Service compatibility is based on policy''':
WSDL can communicate only syntactically for consuming a service. In many cases this is not good enough, especially to share semantic information about consuming the service. The service designer should use the WS-Policy standards for this and should not try to include this somehow into the [http://en.wikipedia.org/wiki/WSDL WSDL]. For example if the government is providing a service to identify miscreants by image comparison. If there is a compliance required from the consumers end about the size and quality of the photo to be used for comparison this should be taken care of using the WS-Policy requirements.
 
*'''[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling]''':
Coupling is a entity which tells us level of dependency that exists between program modules.Ideally speaking there should be zero coupling between modules.
Based on the level/degree of dependencies between modules we have different types of coupling like Content coupling (high), Data coupling, Message coupling (low) and
so on.Good service in SOA should exhibit low coupling as in message coupling
a)message coupling' - this is one of the loosest forms of coupling where in the calling function doesn't know the location of the recipient and has very less
knowledge of the recipient.
 
*'''[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion]'''
Another important concept that need to be discussed with respect to SOA is cohesion.Cohesion tells us about how the parts/sections in the service are related to
each other.Ideally modules should have very cohesion.Good service in SOA should exhibit one of the following types of cohesion:
a)Functional Cohesion: Here module does only one thing , such type of services are highly reusable.
b)Sequential Cohesion: module does several tasks and that must be in order.
c)Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

In Summary ,service we design should have loose coupling and have high cohesion.

=='''Design Patterns associated with SOA'''==
With the background of general [[#design |design principles]] of service from the previous sections now lets study deeper and more involved subject - "Design pattern associated with service" in this section.

Now Lets study some of the design patterns associated with SOA:-
* '''The Document Processor''': The document processor pattern solves the problem of providing a simple and well-defined contract for a service. A contract as mentioned earlier needs to be granular and very well-defined so that no assumptions about its capabilities need to be made. This can be done by using the OOA/OOD principle of "program to an interface". In a service scenario this would mean define the contract first. That is to define a XML schema to request and the response message, then based on this schema the implementation needs to be done.

Example:
Suppose assume, we are designing a service which does fetch us public tweets based on the search term specified, According to this pattern we must first specify what input does this service is going to input and similarly w.r.to output.
Input for above example case would be, search term in the form of regular expression.
Output for the example would be list of tweets.
Once input/outputs are Identified, next step would be to define them XML schema.Once the XML schema is done we start off with design/development of service.

 
* '''The idempotent message''': This design pattern solves the generic problem of multiple deliveries of the same request where a single request needs to be sent. This is usually observed in transition based systems. To ensure idem-potency, the service contract should be designed in such a way that a unique identifier should be tagged per request. Although unique identifier for each request is part of the agreement it should not assumed that these numbers will remain unique over time. The identifier should be considered as a unit of work and work should be performed once for each unique identifier. Duplicates can be handled in many ways depending on the system.
Example:

For example consider a "order service", which accepts order requests from service consumers and places an order.If the consumer doesn't get any response for the service requested it thinks that the order request might have been lost , so it tries to re-send the request,Problem here would be the order request is called twice and it has side effects of sending the order twice.One approach to this should be design a service in idempotent fashion .In the above example the "oder request" service could be split into
# createOrder - it returns unique identifier for each request.
# setOrderDetails - place an order based on the unique id and order details mentioned as part of service request.

The createOrder capability would return an orderId that would then be used when the consumer invokes the setOrderDetails capability. If the createOrder capability is invoked two times instead of one the result would be an extI have taken your APC assignment ra orderId, but since it would have no order details it would not lead to anything being delivered to the customer. If the setOrderDetails is invoked two times it should not matter for either the consumer or the service since the setOrderDetails capability is idempotent

 
* '''Reservation''': This problem solves the problem of maintaining data consistency for long running transactions. We take an approach of creating tentative operations so that database still remains consistent but still we keep a record of ongoing transactions. These tentative operations can go thorough one of these paths. First one is where it operation is completed as all the required messages are completed and the database is updated. The operation is canceled either implicitly due to inconsistency of data etc, or explicitly by the consumer. These services should have certain amount of service levels(time outs) which are explicitly mentioned in the contract and the third possibility is that the service get aborted due to service level considerations.

 

=='''SOA vs Enterprise Architecture'''==
SOA and Enterprise Architecture are two concepts that people tend to confuse with each other .To clarify it, lets us dicuss some of the differences and commonalities between these concepts .Enterprise Architecture discipline defines and maintains the architecture models, governance and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals. So SOA is one of many ways of implementing the IT part of the enterprise architecture. They are similar because both these concepts strive to closely align IT with business, they share similar planning and strategies. The major differences are EA focuses on defining different business components and SOA focuses on providing business services to help these components interact with each other.
 
Lets summarize some of the highlighting things and close this section
Some of the similarities and differences between SOA and EA:
Similarities:
* Both address similar architectural domains - Business,Applications,Integration and Middleware and so on.
* Both are used in the field of IT business and they align with IT business.
* Both of them work using businness requirements/business objective as input.
* Both SOA and EA need similar planning and strategies to work.

Differences:
To make things more clear lets draw out differences between Service Oriented Architecture and Enterprise architecture in the form of table.

{|cellspacing="0" border="2" style="color:black; background-color:Grey;"
!style="width:25%"|Enterprise Architecture
!style="width:25%"|Service Oriented Architecture
|-
|EA deals with application frameworks and enterprise applications
|SOA's scope is on service modeling only
|-
|EA focuses on defining business components,
|SOA focuses on business services
|-
|EA addresses enterprise integration patterns and when they should be used.
|SOA provides an integration approach based on using services.
|-

|EA deals with enterprise-level infrastructure including servers, databases
|SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
|-
|} 

=='''References'''==
* Bloor, Robin, Judith Hurwitz, Marcia Kaufman, and Fern Halper. Service Oriented Architecture . 2nd ed. Hoboken: For Dummies [Imprint], 2009. Print.
* Juneja, Girish. Service oriented architecture demystified . Hillsboro, Or.: Intel Press, 2007. Print.
* Hariharan, Charanya, and Brian H. Cameron. Enterprise architecture & service oriented architecture . University Park, Pa.: Pennsylvania State University, 2009. Print.

=='''External links'''==
*[http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html "Stefan Tilkov: 10 Principles of SOA." Web log post. InnoQ: Home. Web. 18 Nov. 2010.] [http://www.innoq.com/blog/st/2006/12/13/10_principles_of_soa.html 1].
*[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html "Gartner: SOA Design Patterns." Weblog post. Service Oriented Enterprise. Web. 23 Nov. 2010 ] [http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html 2].
*[http://msdn.microsoft.com/en-us/library/ms954638.aspx Microsoft Corporation, Architecture Strategy, John Evdemon. "Principles of Service Design: Service Patterns and Anti-Patterns." MSDN | Microsoft Development, Subscriptions, Resources, and More. 2005. Web. 23 Nov. 2010.] [http://msdn.microsoft.com/en-us/library/ms954638.aspx 3].
*[http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 IBM, Dr. Mamdouh Ibrahim. "Service-Oriented Architecture and Enterprise Architecture, Part 2: Similarities and Differences." IBM - United States. 21 May 2007.Web. 23 Nov. 2010] [http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise2 4]
*[http://en.wikipedia.org/wiki/Service-oriented_architectur "Service-oriented Architecture." Wikipedia, the Free Encyclopedia. Web.] [http://en.wikipedia.org/wiki/Service-oriented_architecture.Web. 23 Nov. 2010 5].
*[http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html Douglas .K. Bary. "Service-oriented Architecture (SOA) Definition." Web Services and Service-Oriented Architectures. Web][http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html.Web. 23 Nov. 2010 6].

CSC/ECE 517 Fall 2010/ch6 6j ps

2010-11-18T01:06:09Z

Smkakara: /* '''Need for SOA??''' */

=='''Introduction'''==
SOA is an architectural approach to creating systems built using autonomous services. SOA brings the emphasis to integration of services and there orchestration to build applications. SOA usually seems like a natural development to all the existing methods to do enterprise wide integration of applications.
Concepts of SOA like services, discovery and late binding etc are from older middleware solutions like CORBA. The SOA design principles too are similar to the previously existing OOA/OOD techniques like encapsulation, abstraction and well defined interfaces.

=='''Need for SOA??'''==

To appreciate SOA, one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture.
Consider the example of bank. Say the bank is currently handling credit card division, and it developed a software to handle all its transactions.
This software developed is a collection and interaction of various modules like getuserinformation, checking balance , check credit card history and process
payments and so on. Say at some later point of time, bank started debit card division and again now to handle all its debit card related functionality
it needs one more software, this software has almost the same functionality as the credit card software, with some differences in functionality.
Now the possible solutions bank can think in developing the software for debit card division would be :-
* Take the same code and make changes to it: The problem with this approach is code duplication and maintainability. Say if bug crops in one of the existing modules we now need to change at 2 places one in credit card software and another in debit card software. If company thinks of developing the debit card software using new programming language, then even code reuse is not possible.
* Object oriented approach of inheriting objects: One might say bank can use Object oriented approach and derive class and functionalities and so on. Even then we have a problem with this approach, we can't alter the existing credit card software if we had to and even maintainability is problem over here. As discussed previously, if bank thinks of writing new software in a different programming language then this solution gets completely ruled out.

This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service. Each service communicates with other services and service consumers using data representation methods like XML(eXtensible Markup Language) as compared to function calls in the conventional programming languages. With this approach we have many advantages

* Reusable code in the form of services: Code is reused in the form of services.
* Code is easily maintainable: As functionality is offered as a service and it is in a single place. It is also autonomous.
* Support for legacy functions: We can reuse legacy functions by writing wrapper around the functionality and make it interact with other services using XML.
* Platform and language independant services: as services interact with each other through XML so the service and the service consumer need not be in the same programming language.

===Without SOA===
 
[[Image:SOA_diagrams2.jpg]]
 
 

===With SOA===
 
[[Image:service_diagrams2.jpg]]
 

=='''Technical jargons associated with SOA'''==
Lets explain this using the above example itself.
# Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
# Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
# Directory services: - After each service is created it registers itself to directory service so that service can be easily located by the consumer of services. whenever consumer wants to utilize the functionality ,he will enquire the directory service and locate the service.

=='''Design principles of Services in SOA'''==
===Overview of key principles of services===
* Service Loose Coupling - According to this principle service should be designed in such a way that it reduces the dependency of given service on other service.
* Service Abstraction - service should be like a black box, it should hide the implementation details from the outside world.
* Service Reusability - services should be implemented in such a fashion that it should be more reusable.
* Service Statelessness - Service should be implemented in such a fashion that it tries to minimize the amount of state information it store. It should store the state information if its really necessary.
* Service Discoverability - Each service should be associated with meta data, this allows us to discover the service and what it does, its i/p requirements.
* Service Autonomy - For the service to work correctly and reliably it should have some amount of control on its underlying environment.According to this principle only limited autonomy is provided to the service such that it works correctly.

===Deep dive into the design principles of services===
Following are some of the key tenets that needs to be discussed in details:-
 
*Boundaries are Explicit 
A service's boundry is its interface to the outside world which is published using a WSDL(Web Services Description Language). Principles which we have to keep in
mind while we design SOA systems which come under this tenet are, Services should be easy to consume. That is a developer should be able to write software easily
by consuming the services. The services should be designed keeping evolution in mind. Services built should be granular so that they can be easily reused.

*Services are autonomous
Services are independtly designed, implemented, deployed and versioned. A designer should not make any assumptions about the service and its capabilites
other than what is provided by the contract. For example if a network latency was assumed and if the computer was moved to a new topology then the network
latency can change. Principles under this tenet a service designer should know are, We should be pessimistic about a service and its capabilities other than
the ones mentioned in the WSDL. We should also be pessimistic about the consumer of the services, so a lot error handling and compensation should be provided.
Services should be versioned independent of the systems that consume them.
 
*Services Share Schema and Contract, Not Class:
Make sure that a service contract remains stable and use the extensible properties of XML and SOAP(optional headers) to add any exceptions. We are refering to the WSDL when we say contract in the above statement. Version services in case changes are unavoidable there by ensuring compliance to all the consumers.
 
*Service compatibility is based on policy :
WSDL can communicate only syntactic for consuming a service. Many cases this is not good enough especially to share semantic information about consuming the service. The service designer should use the WS-Policy standards for this and should not try to include this somehow into the WSDL. For example if the government is providing a service to identify miscreants by image comparison. If there is a compliance required from the consumers end about the size and quality of the photo to be used for comparison this should be taken care of using the WS-Policy requirements.
 
*Coupling:
Coupling is a entity which tells us level of dependency that exists between program modules.Ideally speaking there should be zero coupling between modules.
Based on the level/degree of dependencies between modules we have different types of coupling like Content coupling (high), Data coupling, Message coupling (low) and
so on.Good service in SOA should exhibit low coupling as in message coupling
a)message coupling' - this is one of the loosest forms of coupling where in the calling function doesn't know the location of the recipient and has very less
knowledge of the recipient.
 
*Cohesion
Another important concept that need to be discussed with respect to SOA is cohesion.Cohesion tells us about how the parts/sections in the service are related to
each other.Ideally modules should have very cohesion.Good service in SOA should exhibit one of the following types of cohesion:
a)Functional Cohesion: Here module does only one thing , such type of services are highly reusable.
b)Sequential Cohesion: module does several tasks and that must be in order.
c)Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

In Summary ,service we design should have loose coupling and have high cohesion.

=='''Design Patterns associated with SOA''' ==
Now Lets study some of the design patterns associated with SOA:-
* The Document Processor: The document processor pattern solves the problem of providing a simple and well-defined contract for a service. A contract as mentioned earlier needs to be granular and very well-defined so that no assumptions about its capabilities need to be made. This can be done by using the OOA/OOD principle of "program to an interface". In a service scenario this would mean define the contract first. That is to define a XML schema to request and the response message, then based on this schema the implementation needs to be done.

* The idempotent message: This design pattern solves the generic problem of multiple deliveries of the same request where a single request needs to be sent. This is usually observed in transition based systems. To ensure impotency the service contract should be designed in such a way that a unique identifier should be tagged per request. Although unique identifier for each request is part of the agreement it should not assumed that these numbers will remain unique over time. The identifier should be considered as a unit of work and work should be performed once for each unique identifier. Duplicates can be handled in many ways depending on the system

* Reservation: This problem solves the problem of maintaining data consistency for long running transactions. We take an approach of creating tentative operations so that database still remains consistent but still we keep a record of ongoing transactions. These tentative operations can go thorough one of these paths. First one is where it operation is completed as all the required messages are completed and the database is updated. The operation is canceled either implicitly due to inconsistency of data etc, or explicitly by the consumer. These services should have certain amount of service levels(time outs) which are explicitly mentioned in the contract and the third possibility is that the service get aborted due to service level considerations.

=='''SOA vs Enterprise Architecture'''==
SOA to be understood well in the present scenario is often compared and contraseted with the enterprise architecuture frameworks. We would like to discuss some points about this here. EA is defined as "The EA discipline defines and maintains the architecture models, governance and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals". So SOA is one of many ways of implementing the IT part of the enterprise architecture. They are similar because both these concepts strive to closely align IT with business, they share similar planning and stratagies. The major differences are EA focuses on defining different business components and SOA focuses on providing business services to help these components interact with each other.

=='''References'''==
* Bloor, Robin, Judith Hurwitz, Marcia Kaufman, and Fern Halper. Service Oriented Architecture . 2nd ed. Hoboken: For Dummies [Imprint], 2009. Print.
* Juneja, Girish. Service oriented architecture demystified . Hillsboro, Or.: Intel Press, 2007. Print.
* Hariharan, Charanya, and Brian H. Cameron. Enterprise architecture & service oriented architecture . University Park, Pa.: Pennsylvania State University, 2009. Print.

=='''External links'''==
* http://en.wikipedia.org/wiki/Service-oriented_architecture
* http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html
* http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci929153,00.html

CSC/ECE 517 Fall 2010/ch6 6j ps

2010-11-18T00:43:20Z

Smkakara: /* Introduction */

==Introduction==
SOA is an architectural approach to creating systems built using autonomous services. SOA brings the emphasis to integration of services and there orchestration to build applications. SOA usually seems like a natural development to all the existing methods to do enterprise wide integration of applications.
Concepts of SOA like services, discovery and late binding etc are from older middleware solutions like CORBA. The SOA design principles too are similar to the previously existing OOA/OOD techniques like encapsulation, abstraction and well defined interfaces.

==Need for SOA??==

To appreciate SOA, one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture.
Consider the example of bank.Say the bank is currently handling credit card division , and it developed a software to handle all its transactions.
This software developed is a collection and interaction of various modules like getuserinformation, checking balance , check credit card history and process
payments and so on .Say at some later point of time, bank started debit card division and again now to handle all its debit card related functionality
it need one more software and it does almost have similar functionality as credit card ,with some differences in functionality.
Now the possible solutions bank can think in developing the software for debit card division would be :-
* Take same code and make changes to it : The problem with this approach is code duplication and maintainablity.Say if bug crops in one of the module we now need to change at 2 places one in credit card software and another in debit card software.If company thinks of developing the debit card software using new programming language ,then even code reuse is not possible.
* Object oriented approach of inheriting objects: One might say bank can use Object oriented approach and derive class and functionalities and so on.Even then we have problem with this approach, we can't tamper the existing credit card software and even maintainability is problem over here.As discussed previously, if bank thinks of writing new software in different programming language then this solution also gets ruled out.

This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service .Each service to exploit the functionality of other service communicates to it using languages like 'xml' as compared to function calls in convention programming language.With this approach we have many advantages

* Reusable code in the form of services: Code is reused in the form of services.
* Code is easily maintainable:- as functionality is offered as a service and it is single place .
* Support for legacy functions:We can reuse legacy functions by writing wrapper around the functionality and make it interact with other services using XML.
* Platform and language independant services - as services interact with each other through xml so there is no requirement of both functions in same programming language.

==='''Without SOA'''===
 
[[Image:Presoa.PNG]]
 
 
==='''With SOA'''===
 
 
[[Image:Soa.PNG]]
 

==Technical jargons associated with SOA==
Lets explain this using the above example itself.
* Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
* Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
* Directory services: - After each service is created it registers itself to directory service so that service can be easily located by the consumer of services. whenever consumer wants to utilize the functionality ,he will enquire the directory service and locate the service.

==Design principles of Services in SOA==

=== Overview of key principles of services ===
* Service Loose Coupling - According to this principle service should be designed in such a way that it reduces the dependency of given service on other service.
* Service Abstraction - service should be like a black box, it should hide the implementation details from the outside world.
* Service Reusability - services should be implemented in such a fashion that it should be more reusable.
* Service Statelessness - Service should be implemented in such a fashion that it tries to minimize the amount of state information it store. It should store the state information if its really necessary.
* Service Discoverability - Each service should be associated with meta data, this allows us to discover the service and what it does, its i/p requirements.
* Service Autonomy - For the service to work correctly and reliably it should have some amount of control on its underlying environment.According to this principle only limited autonomy is provided to the service such that it works correctly.

===Deep dive into the design principles of services ===
Following are some of the key tenets that needs to be discussed in details:-
 
*'''Boundaries are Explicit''' 
A service's boundry is its interface to the outside world which is published using a WSDL(Web Services Description Language). Principles which we have to keep in
mind while we design SOA systems which come under this tenet are, Services should be easy to consume. That is a developer should be able to write software easily
by consuming the services. The services should be designed keeping evolution in mind. Services built should be granular so that they can be easily reused.

*'''Services are autonomous'''
Services are independtly designed, implemented, deployed and versioned. A designer should not make any assumptions about the service and its capabilites
other than what is provided by the contract. For example if a network latency was assumed and if the computer was moved to a new topology then the network
latency can change. Principles under this tenet a service designer should know are, We should be pessimistic about a service and its capabilities other than
the ones mentioned in the WSDL. We should also be pessimistic about the consumer of the services, so a lot error handling and compensation should be provided.
Services should be versioned independent of the systems that consume them.
 
*'''Services Share Schema and Contract, Not Class:'''
Make sure that a service contract remains stable and use the extensible properties of XML and SOAP(optional headers) to add any exceptions. We are refering to the WSDL when we say contract in the above statement. Version services in case changes are unavoidable there by ensuring compliance to all the consumers.
 
*'''Service compatibility is based on policy :'''
WSDL can communicate only syntactic for consuming a service. Many cases this is not good enough especially to share semantic information about consuming the service. The service designer should use the WS-Policy standards for this and should not try to include this somehow into the WSDL. For example if the government is providing a service to identify miscreants by image comparison. If there is a compliance required from the consumers end about the size and quality of the photo to be used for comparison this should be taken care of using the WS-Policy requirements.
 
*'''Coupling:'''
Coupling is a entity which tells us level of dependency that exists between program modules.Ideally speaking there should be zero coupling between modules.
Based on the level/degree of dependencies between modules we have different types of coupling like Content coupling (high), Data coupling, Message coupling (low) and
so on.Good service in SOA should exhibit low coupling as in message coupling
a)message coupling' - this is one of the loosest forms of coupling where in the calling function doesn't know the location of the recipient and has very less
knowledge of the recipient.
 
*'''Cohesion'''
Another important concept that need to be discussed with respect to SOA is cohesion.Cohesion tells us about how the parts/sections in the service are related to
each other.Ideally modules should have very cohesion.Good service in SOA should exhibit one of the following types of cohesion:
a)Functional Cohesion: Here module does only one thing , such type of services are highly reusable.
b)Sequential Cohesion: module does several tasks and that must be in order.
c)Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.

In Summary ,service we design should have loose coupling and have high cohesion.

==Design Patterns associated with SOA ==
Now Lets study some of the design patterns associated with SOA:-
* The Document Processor: The document processor pattern solves the problem of providing a simple and well-defined contract for a service. A contract as mentioned earlier needs to be granular and very well-defined so that no assumptions about its capabilities need to be made. This can be done by using the OOA/OOD principle of "program to an interface". In a service scenario this would mean define the contract first. That is to define a XML schema to request and the response message, then based on this schema the implementation needs to be done.

* The idempotent message: This design pattern solves the generic problem of multiple deliveries of the same request where a single request needs to be sent. This is usually observed in transition based systems. To ensure impotency the service contract should be designed in such a way that a unique identifier should be tagged per request. Although unique identifier for each request is part of the agreement it should not assumed that these numbers will remain unique over time. The identifier should be considered as a unit of work and work should be performed once for each unique identifier. Duplicates can be handled in many ways depending on the system

* Reservation: This problem solves the problem of maintaining data consistency for long running transactions. We take an approach of creating tentative operations so that database still remains consistent but still we keep a record of ongoing transactions. These tentative operations can go thorough one of these paths. First one is where it operation is completed as all the required messages are completed and the database is updated. The operation is canceled either implicitly due to inconsistency of data etc, or explicitly by the consumer. These services should have certain amount of service levels(time outs) which are explicitly mentioned in the contract and the third possibility is that the service get aborted due to service level considerations.

== SOA vs Enterprise Architecture ==
SOA to be understood well in the present scenario is often compared and contraseted with the enterprise architecuture frameworks. We would like to discuss some points about this here. EA is defined as "The EA discipline defines and maintains the architecture models, governance and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals". So SOA is one of many ways of implementing the IT part of the enterprise architecture. They are similar because both these concepts strive to closely align IT with business, they share similar planning and stratagies. The major differences are EA focuses on defining different business components and SOA focuses on providing business services to help these components interact with each other.

==References==
* Bloor, Robin, Judith Hurwitz, Marcia Kaufman, and Fern Halper. Service Oriented Architecture . 2nd ed. Hoboken: For Dummies [Imprint], 2009. Print.
* Juneja, Girish. Service oriented architecture demystified . Hillsboro, Or.: Intel Press, 2007. Print.
* Hariharan, Charanya, and Brian H. Cameron. Enterprise architecture & service oriented architecture . University Park, Pa.: Pennsylvania State University, 2009. Print.

==External links==
* http://en.wikipedia.org/wiki/Service-oriented_architecture
* http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html
* http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci929153,00.html

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-14T04:10:25Z

Smkakara: /* Singleton Pattern in Java */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. Its unique behavior of having just one object and serving up the same object whenever requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to go against this notion and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. All these constraints make implementation of singleton pattern in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic] and static languages interesting.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things, this means that type checking is done during [http://en.wikipedia.org/wiki/Compile_time compile time] in Java.
 
'''Implementation'''
:Singleton pattern in Java is implemented considering the 4 steps mention below:
*Create a default [http://en.wikipedia.org/wiki/Constructor_(object-oriented_programming) constructor] and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by [http://en.wikipedia.org/wiki/Method_overriding overriding] the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. It prevents a developer from creating an object of the class by using this line of code - ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is created if a singleton object doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using [http://en.wikipedia.org/wiki/Lazy_initialization lazy instantiation] which means that the object is created only when the initialize method is called for the first time. We could have also used early instantiation. In that case,
the object would be instantiated when the class is loaded.
 
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and ensures that only one object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method. So, instead of synchronizing the whole method we could just synchronize the block of code which creates the new object.

<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done using this line of code - ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same constraints as in Java. So we can write the ruby equivalent of the code above and we will have the Ruby singleton pattern.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using early instantiation as you can see. We might have to lock the instance method with [http://ruby-doc.org/core/classes/Mutex.html mutex]. Even though the code seems smaller and simpler compared to Java's implementation, it is still a lot of things to do. So, Ruby provides a simpler way to do it. [http://ruby-doc.org/stdlib/ Ruby standard library] has a [http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html singleton module] which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.

Nevertheless, since Ruby provides us a standard library module to code a Singleton pattern, the implementation is simplified to a great extent when compared to Java. As seen above, the complexity of the code and the number of lines needed for the implementation of the Singleton pattern is drastically reduced using the Singleton module of the Ruby standard library.

==References==
#[http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html Ruby documentation for Singleton module]
#http://en.wikipedia.org/wiki/Singleton_pattern
#http://www.javabeginner.com/learn-java/java-singleton-design-pattern
#[http://oreilly.com/catalog/9780596007126 Head First Java book]

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-14T04:07:20Z

Smkakara: /* Conclusion */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. Its unique behavior of having just one object and serving up the same object whenever requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to go against this notion and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. All these constraints make implementation of singleton pattern in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic] and static languages interesting.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things, this means that type checking is done during compile time in Java.
 
'''Implementation'''
:Singleton pattern in Java is implemented considering the 4 steps mention below:
*Create a default [http://en.wikipedia.org/wiki/Constructor_(object-oriented_programming) constructor] and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by [http://en.wikipedia.org/wiki/Method_overriding overriding] the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. It prevents a developer from creating an object of the class by using this line of code - ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is created if a singleton object doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using [http://en.wikipedia.org/wiki/Lazy_initialization lazy instantiation] which means that the object is created only when the initialize method is called for the first time. We could have also used early instantiation. In that case,
the object would be instantiated when the class is loaded.
 
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and ensures that only one object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method. So, instead of synchronizing the whole method we could just synchronize the block of code which creates the new object.

<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done using this line of code - ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same constraints as in Java. So we can write the ruby equivalent of the code above and we will have the Ruby singleton pattern.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using early instantiation as you can see. We might have to lock the instance method with [http://ruby-doc.org/core/classes/Mutex.html mutex]. Even though the code seems smaller and simpler compared to Java's implementation, it is still a lot of things to do. So, Ruby provides a simpler way to do it. [http://ruby-doc.org/stdlib/ Ruby standard library] has a [http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html singleton module] which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.

Nevertheless, since Ruby provides us a standard library module to code a Singleton pattern, the implementation is simplified to a great extent when compared to Java. As seen above, the complexity of the code and the number of lines needed for the implementation of the Singleton pattern is drastically reduced using the Singleton module of the Ruby standard library.

==References==
#[http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html Ruby documentation for Singleton module]
#http://en.wikipedia.org/wiki/Singleton_pattern
#http://www.javabeginner.com/learn-java/java-singleton-design-pattern
#[http://oreilly.com/catalog/9780596007126 Head First Java book]

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-14T04:03:28Z

Smkakara: /* Singleton pattern in Ruby */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. Its unique behavior of having just one object and serving up the same object whenever requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to go against this notion and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. All these constraints make implementation of singleton pattern in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic] and static languages interesting.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things, this means that type checking is done during compile time in Java.
 
'''Implementation'''
:Singleton pattern in Java is implemented considering the 4 steps mention below:
*Create a default [http://en.wikipedia.org/wiki/Constructor_(object-oriented_programming) constructor] and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by [http://en.wikipedia.org/wiki/Method_overriding overriding] the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. It prevents a developer from creating an object of the class by using this line of code - ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is created if a singleton object doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using [http://en.wikipedia.org/wiki/Lazy_initialization lazy instantiation] which means that the object is created only when the initialize method is called for the first time. We could have also used early instantiation. In that case,
the object would be instantiated when the class is loaded.
 
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and ensures that only one object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method. So, instead of synchronizing the whole method we could just synchronize the block of code which creates the new object.

<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done using this line of code - ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same constraints as in Java. So we can write the ruby equivalent of the code above and we will have the Ruby singleton pattern.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using early instantiation as you can see. We might have to lock the instance method with [http://ruby-doc.org/core/classes/Mutex.html mutex]. Even though the code seems smaller and simpler compared to Java's implementation, it is still a lot of things to do. So, Ruby provides a simpler way to do it. [http://ruby-doc.org/stdlib/ Ruby standard library] has a [http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html singleton module] which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in Java and Ruby.

==References==
#[http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html Ruby documentation for Singleton module]
#http://en.wikipedia.org/wiki/Singleton_pattern
#http://www.javabeginner.com/learn-java/java-singleton-design-pattern
#[http://oreilly.com/catalog/9780596007126 Head First Java book]

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-14T04:02:34Z

Smkakara: /* Singleton Pattern in Java */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. Its unique behavior of having just one object and serving up the same object whenever requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to go against this notion and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. All these constraints make implementation of singleton pattern in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic] and static languages interesting.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things, this means that type checking is done during compile time in Java.
 
'''Implementation'''
:Singleton pattern in Java is implemented considering the 4 steps mention below:
*Create a default [http://en.wikipedia.org/wiki/Constructor_(object-oriented_programming) constructor] and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by [http://en.wikipedia.org/wiki/Method_overriding overriding] the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. It prevents a developer from creating an object of the class by using this line of code - ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is created if a singleton object doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using [http://en.wikipedia.org/wiki/Lazy_initialization lazy instantiation] which means that the object is created only when the initialize method is called for the first time. We could have also used early instantiation. In that case,
the object would be instantiated when the class is loaded.
 
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and ensures that only one object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method. So, instead of synchronizing the whole method we could just synchronize the block of code which creates the new object.

<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done using this line of code - ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same constraints as in Java. So we can write the ruby equivalent of the code above and we will have the Ruby singleton pattern.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using early instantiation as you can see. We might have to lock the instance method with [http://ruby-doc.org/core/classes/Mutex.html mutex]. Even though the code seems smaller and simpler compared to Java's implementation, it is still a lot of things to do. So, Ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in Java and Ruby.

==References==
#[http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html Ruby documentation for Singleton module]
#http://en.wikipedia.org/wiki/Singleton_pattern
#http://www.javabeginner.com/learn-java/java-singleton-design-pattern
#[http://oreilly.com/catalog/9780596007126 Head First Java book]

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-14T03:59:26Z

Smkakara: /* Singleton pattern in Ruby */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. Its unique behavior of having just one object and serving up the same object whenever requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to go against this notion and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. All these constraints make implementation of singleton pattern in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic] and static languages interesting.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things, this means that type checking is done during compile time in Java.
 
'''Implementation'''
:Singleton pattern in Java is implemented considering the 4 steps mention below:
*Create a default [http://en.wikipedia.org/wiki/Constructor_(object-oriented_programming) constructor] and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by [http://en.wikipedia.org/wiki/Method_overriding overriding] the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. It prevents a developer from creating an object of the class by using this line of code - ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is created if a singleton object doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation which means that the object is created only when the initialize method is called for the first time. We could have also used early instantiation. In that case,
the object would be instantiated when the class is loaded.
 
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and ensures that only one object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method. So, instead of synchronizing the whole method we could just synchronize the block of code which creates the new object.

<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done using this line of code - ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same constraints as in Java. So we can write the ruby equivalent of the code above and we will have the Ruby singleton pattern.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using early instantiation as you can see. We might have to lock the instance method with [http://ruby-doc.org/core/classes/Mutex.html mutex]. Even though the code seems smaller and simpler compared to Java's implementation, it is still a lot of things to do. So, Ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in Java and Ruby.

==References==
#[http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html Ruby documentation for Singleton module]
#http://en.wikipedia.org/wiki/Singleton_pattern
#http://www.javabeginner.com/learn-java/java-singleton-design-pattern
#[http://oreilly.com/catalog/9780596007126 Head First Java book]

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-14T03:49:15Z

Smkakara: /* Singleton Pattern in Java */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. Its unique behavior of having just one object and serving up the same object whenever requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to go against this notion and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. All these constraints make implementation of singleton pattern in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic] and static languages interesting.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things, this means that type checking is done during compile time in Java.
 
'''Implementation'''
:Singleton pattern in Java is implemented considering the 4 steps mention below:
*Create a default [http://en.wikipedia.org/wiki/Constructor_(object-oriented_programming) constructor] and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by [http://en.wikipedia.org/wiki/Method_overriding overriding] the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. It prevents a developer from creating an object of the class by using this line of code - ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is created if a singleton object doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation which means that the object is created only when the initialize method is called for the first time. We could have also used early instantiation. In that case,
the object would be instantiated when the class is loaded.
 
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and ensures that only one object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method. So, instead of synchronizing the whole method we could just synchronize the block of code which creates the new object.

<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done using this line of code - ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same aspects as in Java. So we can just write the ruby equivalent of the code above and we have the Ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in Java and Ruby.

==References==
#[http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html Ruby documentation for Singleton module]
#http://en.wikipedia.org/wiki/Singleton_pattern
#http://www.javabeginner.com/learn-java/java-singleton-design-pattern
#[http://oreilly.com/catalog/9780596007126 Head First Java book]

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-14T03:40:15Z

Smkakara: /* Singleton Pattern in Java */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. Its unique behavior of having just one object and serving up the same object whenever requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to go against this notion and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. All these constraints make implementation of singleton pattern in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic] and static languages interesting.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things, this means that type checking is done during compile time in Java.
 
'''Implementation'''
:Singleton pattern in Java is implemented considering the 4 steps mention below:
*Create a default [http://en.wikipedia.org/wiki/Constructor_(object-oriented_programming) constructor] and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by [http://en.wikipedia.org/wiki/Method_overriding overriding] the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. It prevents a developer from creating an object of the class by using this line of code - ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is created if a singleton object doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation which means that the object is created only when the initialize method is called for the first time. We could have also used early instantiation. In that case,
the object would be instantiated when the class is loaded.
 
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method.

<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same aspects as in Java. So we can just write the ruby equivalent of the code above and we have the Ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in Java and Ruby.

==References==
#[http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html Ruby documentation for Singleton module]
#http://en.wikipedia.org/wiki/Singleton_pattern
#http://www.javabeginner.com/learn-java/java-singleton-design-pattern
#[http://oreilly.com/catalog/9780596007126 Head First Java book]

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-14T03:38:11Z

Smkakara:

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. Its unique behavior of having just one object and serving up the same object whenever requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to go against this notion and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. All these constraints make implementation of singleton pattern in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamic] and static languages interesting.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things, this means that type checking is done during compile time in Java.
 
'''Implementation'''
:Singleton pattern in Java is implemented considering the 4 steps mention below:
*Create a default [http://en.wikipedia.org/wiki/Constructor_(object-oriented_programming) constructor] and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by [http://en.wikipedia.org/wiki/Method_overriding overriding] the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. It prevents a developer from creating an object of the class by using this line of code - ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is created if a singleton object doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation which means that the object is created only when the initialize method is called for the first time. We could have also used early instantiation. In that case,
the object would be instantiated when the class is loaded.
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method.

<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same aspects as in Java. So we can just write the ruby equivalent of the code above and we have the Ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in Java and Ruby.

==References==
#[http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html Ruby documentation for Singleton module]
#http://en.wikipedia.org/wiki/Singleton_pattern
#http://www.javabeginner.com/learn-java/java-singleton-design-pattern
#[http://oreilly.com/catalog/9780596007126 Head First Java book]

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-07T02:54:05Z

Smkakara: /* Conclusion */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. To make sure its peculiar behavior of having just one object and serving up the same object when requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to move against this and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. We will discuss the implementation of singleton pattern in dynamic and static languages below.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things this means that type checking is done in compile time in Java.
 
'''Implementation'''
:Singleton pattern in java is implemented considering the 4 steps mention below.
*Create a default constructor and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by overriding the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. This prevents a developer from creating an object of the class by using the ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is being created if a singleton doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation, that means the object is created only when the for the first time the initialize method is called. We could have also used early instantiation in that case
the object would be instantiated when the class is loaded.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method.

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same aspects as in Java. So we can just write the ruby equivalent of the code above and we have the Ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in Java and Ruby.

==References==
#[http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html Ruby documentation for Singleton module]
#http://en.wikipedia.org/wiki/Singleton_pattern
#http://www.javabeginner.com/learn-java/java-singleton-design-pattern
#[http://oreilly.com/catalog/9780596007126 Head First Java book]

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-07T02:52:50Z

Smkakara: /* References */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. To make sure its peculiar behavior of having just one object and serving up the same object when requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to move against this and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. We will discuss the implementation of singleton pattern in dynamic and static languages below.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things this means that type checking is done in compile time in Java.
 
'''Implementation'''
:Singleton pattern in java is implemented considering the 4 steps mention below.
*Create a default constructor and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by overriding the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. This prevents a developer from creating an object of the class by using the ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is being created if a singleton doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation, that means the object is created only when the for the first time the initialize method is called. We could have also used early instantiation in that case
the object would be instantiated when the class is loaded.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method.

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same aspects as in Java. So we can just write the ruby equivalent of the code above and we have the Ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in static an dynamic variables.
==References==
#[http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html Ruby documentation for Singleton module]
#http://en.wikipedia.org/wiki/Singleton_pattern
#http://www.javabeginner.com/learn-java/java-singleton-design-pattern
#[http://oreilly.com/catalog/9780596007126 Head First Java book]

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-07T02:47:44Z

Smkakara: /* Singleton pattern in Ruby */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. To make sure its peculiar behavior of having just one object and serving up the same object when requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to move against this and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. We will discuss the implementation of singleton pattern in dynamic and static languages below.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things this means that type checking is done in compile time in Java.
 
'''Implementation'''
:Singleton pattern in java is implemented considering the 4 steps mention below.
*Create a default constructor and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by overriding the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. This prevents a developer from creating an object of the class by using the ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is being created if a singleton doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation, that means the object is created only when the for the first time the initialize method is called. We could have also used early instantiation in that case
the object would be instantiated when the class is loaded.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method.

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same aspects as in Java. So we can just write the ruby equivalent of the code above and we have the Ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in static an dynamic variables.
==References==

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-07T02:47:15Z

Smkakara: /* Singleton pattern in Ruby */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. To make sure its peculiar behavior of having just one object and serving up the same object when requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to move against this and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. We will discuss the implementation of singleton pattern in dynamic and static languages below.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things this means that type checking is done in compile time in Java.
 
'''Implementation'''
:Singleton pattern in java is implemented considering the 4 steps mention below.
*Create a default constructor and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by overriding the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. This prevents a developer from creating an object of the class by using the ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is being created if a singleton doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation, that means the object is created only when the for the first time the initialize method is called. We could have also used early instantiation in that case
the object would be instantiated when the class is loaded.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method.

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
Ruby has the same aspects as in Java. So we can just write the ruby equivalent of the code above and we have the ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in static an dynamic variables.
==References==

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-07T02:44:37Z

Smkakara: /* Singleton Pattern in Java */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. To make sure its peculiar behavior of having just one object and serving up the same object when requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to move against this and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. We will discuss the implementation of singleton pattern in dynamic and static languages below.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things this means that type checking is done in compile time in Java.
 
'''Implementation'''
:Singleton pattern in java is implemented considering the 4 steps mention below.
*Create a default constructor and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by overriding the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. This prevents a developer from creating an object of the class by using the ''''SingletonObject myObject = new SingletonObject()''''. To get the object of the singleton class
the developer must call the ''SingletonObject.instance()'' method. In the instance method a new object is being created if a singleton doesn’t exist, otherwise the existing
reference to ''SingletonObject'' is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation, that means the object is created only when the for the first time the initialize method is called. We could have also used early instantiation in that case
the object would be instantiated when the class is loaded.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage I/O operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the ''instance()'' method is not necessary after the object is created, that is after the first call to the ''initialize()'' method.

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this ''''SingletonObject clonedObject = (SingletonObject) obj.clone();''''.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
ruby has the same aspects as in java. So we can just write the ruby equivalent of the code above and we have the ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.
==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in static an dynamic variables.
==References==

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-07T02:38:11Z

Smkakara: /* Introduction */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class". Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
it's implementation can be quite a task. To make sure its peculiar behavior of having just one object and serving up the same object when requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to move against this and make sure we have only one object.
We have to take care of multi-threading scenarios, subclassing etc. We will discuss the implementation of singleton pattern in dynamic and static languages below.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things this means that type checking is done in compile time in java.
 
'''Implementation'''
:Singleton pattern in java is implemented considering the 4 steps mention below.
*Create a default constructor and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by overriding the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. This prevents a developer from creating an object of the class by using the SingletonObject myObject = new SingletonObject(). To get the object of the singleton class
the developer must call the SingletonObject.instance() method. In the instance method a new object is being created if a singleton doesn’t exist, otherwise the existing
reference to SingletonObject is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation, that means the object is created only when the for the first time the initialize method is called. We could have also used early instantiation in that case
the object would be instantiated when the class is loaded.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage i/o operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the instance() method is not necessary after the object is created, that is after the first call to the initialize() method.

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this SingletonObject clonedObject = (SingletonObject) obj.clone();.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
ruby has the same aspects as in java. So we can just write the ruby equivalent of the code above and we have the ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.
==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in static an dynamic variables.
==References==

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-07T02:32:21Z

Smkakara: /* Introduction */

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the [http://en.wikipedia.org/wiki/Design_Patterns gang of four].
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class." Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools , to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
It's implementation can be quite a task. To make sure its peculiar behavior of having just one object and serving up the same object when requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to move against this and make sure we have only one object.
We have to take care of multi threading scenarios, subclassing etc. We will discuss the implementation of singleton pattern in dynamic and static languages below.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things this means that type checking is done in compile time in java.
 
'''Implementation'''
:Singleton pattern in java is implemented considering the 4 steps mention below.
*Create a default constructor and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by overriding the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. This prevents a developer from creating an object of the class by using the SingletonObject myObject = new SingletonObject(). To get the object of the singleton class
the developer must call the SingletonObject.instance() method. In the instance method a new object is being created if a singleton doesn’t exist, otherwise the existing
reference to SingletonObject is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation, that means the object is created only when the for the first time the initialize method is called. We could have also used early instantiation in that case
the object would be instantiated when the class is loaded.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage i/o operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the instance() method is not necessary after the object is created, that is after the first call to the initialize() method.

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this SingletonObject clonedObject = (SingletonObject) obj.clone();.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
ruby has the same aspects as in java. So we can just write the ruby equivalent of the code above and we have the ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.
==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in static an dynamic variables.
==References==

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-07T02:02:08Z

Smkakara:

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the gang of four.
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class." Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools , to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
It's implementation can be quite a task. To make sure its peculiar behavior of having just one object and serving up the same object when requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to move against this and make sure we have only one object.
We have to take care of multi threading scenarios, subclassing etc. We will discuss the implementation of singleton pattern in dynamic and static languages below.
==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things this means that type checking is done in compile time in java.
 
'''Implementation'''
:Singleton pattern in java is implemented considering the 4 steps mention below.
*Create a default constructor and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by overriding the object clone method.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. This prevents a developer from creating an object of the class by using the SingletonObject myObject = new SingletonObject(). To get the object of the singleton class
the developer must call the SingletonObject.instance() method. In the instance method a new object is being created if a singleton doesn’t exist, otherwise the existing
reference to SingletonObject is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation, that means the object is created only when the for the first time the initialize method is called. We could have also used early instantiation in that case
the object would be instantiated when the class is loaded.
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage i/o operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the instance() method is not necessary after the object is created, that is after the first call to the initialize() method.

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this SingletonObject clonedObject = (SingletonObject) obj.clone();.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

==Singleton pattern in Ruby==

Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
ruby has the same aspects as in java. So we can just write the ruby equivalent of the code above and we have the ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end
</pre>
This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

The include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.
==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unnecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in static an dynamic variables.
==References==

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-07T01:52:12Z

Smkakara:

==Introduction==

Singleton pattern has the simplest class diagram among all the design patterns discussed by the gang of four.
It has just one class. It has some interesting characteristics. Lets start with the definition itself.

;Singleton
: Ensures a class has only one instance, and provides a global point of access to it.

The definiton can be explained as "we can have one and only one instance of the class." Singleton pattern is useful in cases where you need to interact with input and output devices,
to maintain thread pools , to log events in a single log file etc. Although the class diagram of the singleton class seems simple,
It's implementation can be quite a task. To make sure its peculiar behavior of having just one object and serving up the same object when requested makes it so.
Classes are naturally designed in a way that we create many instances of them. So we have to move against this and make sure we have only one object.
We have to take care of multi threading scenarios, subclassing etc. We will discuss the implementation of singleton pattern in dynamic and static languages below.

==Singleton Pattern in Java==
Java is a statically typed object oriented language. Among other things this means that type checking is done in compile time in java.
 
'''Implementation'''
 
:Singleton pattern in java is implemented considering the 4 steps mention below.
*Create a default constructor and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by overriding the object clone method.
 
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static SingletonObject getSingletonObject() {
if (myObject == null) {
myObject = new SingletonObject();
}
return myObject;
}
}
</pre>
In this code we have followed the first two steps. We are making the default constructor private. This means that the constructor can be accessed only by other methods
inside the class. This prevents a developer from creating an object of the class by using the SingletonObject myObject = new SingletonObject(). To get the object of the singleton class
the developer must call the SingletonObject.instance() method. In the instance method a new object is being created if a singleton doesn’t exist, otherwise the existing
reference to SingletonObject is returned. This way the reference to same object is returned every time the instance method is called. In the above example we are using lazy
instantiation, that means the object is created only when the for the first time the initialize method is called. We could have also used early instantiation in that case
the object would be instantiated when the class is loaded.
 
<pre>
class SingletonObject {

private static SingletonObject myObject;

private SingletonObject() {
// Optional Code
}
public static synchronized SingletonObjec myObject() {
if (myObject == null) {
myObject = new SingletonClass();
}
return myObject;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
</pre>
'''Synchronization and Cloning'''
 
The above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method
there is a possibility that more than one object can get created. So we need to make this method synchronized. This makes sure that only one thread can
access this function at a time and thus ensuring that only object is ever created of the SingletonObject class. Synchronizing the singleton method has
some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.
This may be the case in some singletons which manage i/o operations, write logs to the same file etc. A closerlook at the code can tell us that
synchronizing access to the instance() method is not necessary after the object is created, that is after the first call to the initialize() method.

We can still create a copy of the singleton by cloning it using the Object’s clone method.
It can be done like this SingletonObject clonedObject = (SingletonObject) obj.clone();.
To avoid this we have to override the clone method as shown above. We can just throw an exception when this method is called.

 
==Singleton pattern in Ruby==
 
Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in
ruby has the same aspects as in java. So we can just write the ruby equivalent of the code above and we have the ruby singleton pattern.
Just to show how it looks we have it down here.

<pre>
class SingletonObject
def initialize
#option code
end

@@instance = SingletonObject.new

def self.instance
return @@instance
end

private_class_method :new
end

</pre>

This is how singleton is implemented in ruby. In this case we are using static instantiation as you can see. We might have to use mutex and lock the block of code which runs initialize.
Its still a lot of things to care about, so ruby provides a simpler way to do it. Ruby standard library has a singleton module which we can use.
It defines the initialize method for us. It does lazy instantiation of the singleton object too.

<pre>
require 'singleton'

class SingletonObject
include Singleton
end
</pre>

include Singleton statement in the above code includes all the methods of the Singleton module. The instance method we saw in the previous example is implemented in the
Singleton module. This module uses the lazy instantiation method.

==Conclusion==
Singleton pattern in both languages as seen above has to take care of a lot of implementation details. It is counter intuitive to the concept of objects and classes.
For example subclassing is another important thing to remember when we use the singleton pattern. We cannot subclass the singleton class as it may lead to duplication,
unecessary consequences in the lower classes etc.
Implementation of singleton pattern mostly decides on what tradeoff we are ready to make. If we dont call the initialize method too many times then we can make do with having
it being synchronized. If lazy instantiation is necessary then we have to tradeoff the convinience that comes with using static variables.
So now we have learned to implement the singleton pattern in static an dynamic variables.

 
==References==

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-07T01:29:08Z

Smkakara:

==Introduction==

 
==Singleton==
: Singleton pattern has the simplest class diagram among all the design patterns discussed by the gang of four. It has just one class. It has some interesting characteristics. Lets start with the definition itself.
;'''Singleton'''
* Ensures a class has only one instance, and provides a global point of access to it.
*It means that we can have one and only one instance of the class.
* This is useful in cases where you need to interact with input and output devices, to maintain thread pools, to log events in a single log file etc. Although the class diagram of the singleton class seems simple, Its implementation can be quite a task.
*To make sure its peculiar behavior of having just one object and serving up the same object when requested is non trivial.
 
Classes are naturally designed in a way that we create many instances of them. So we have to move against this and make sure we have only one object.

We have to take care of multi threading scenarios, sub classing etc. We will discuss the implementation of singleton pattern in dynamic and static languages and then compare and contrast the two.
 
'''Singleton Pattern in Java'''
 
Java is a statically typed object oriented language. Among other things this means that type checking is done in compile time in java.
 
'''Implementation'''
 
Singleton pattern in java is implemented considering the 4 steps mention below.
*Create a default constructor and make it private.
*Create a method for getting the reference to the singleton object.
* Make the access method synchronized to prevent thread issues.
* Prevent cloning of the object by overriding the object clone method.
 
In this step we are making the default constructor private. This means that the constructor can be accessed only by other methods inside the class. This prevents a developer from creating an object of the class by using the myObject name = new myObject() method. To get the object of the singleton class the developer must call the myObject.instance() method.
In the instance method a new object is being created if a singleton doesn’t exist, otherwise the existing singleton is returned. This way the reference to same object is returned every time instance is called. (lazy initialization)
 
'''Synchronization'''
 
Above code seems to be good enough for a singleton pattern, but when we take a closer look we realize that when multiple threads access this instance method, there is a possibility that more than one object gets created. So we need to make this method synchronized. This makes sure that only one thread can access this function at a time and thus ensuring that only object is ever created of the singleton class.
 
'''Consequences of Synchronization'''
 
Synchronizing the singleton method has some consequences. This may result in performance loss if the singleton instance method is being accessed a lot of times in our over all application.This may be the case in some singletons which manage i/o operations, write logs to the same file etc. A closer look at the code can tell you that synchronizing access to the instance() method is not necessary after the object is created.
 
'''Creating the clone'''
 
We can still create a copy of the singleton by cloning it using the Object’s clone method. This can be done as shown SingletonObject clonedObject = (SingletonObject) obj.clone();.To avoid this we have to override the clone method as well. We can just throw an exception when this method is called. (sub classing)

 
==Singleton pattern in Ruby==
 
Ruby is a dynamically typed object oriented language. This means type checking happens at run time. Implementing the singleton pattern in ruby has the same aspects as in java. So we can just write the ruby equivalent of the code above and we have the ruby singleton pattern. Just to show how it looks we have it down here.

<code>
require 'singleton'
class Logger
include Singleton

def initialize
@log = File.open("log.txt", "a")
end

def log(msg)
@log.puts(msg)
end
end
Logger.instance.log('message 2')
</code>

This looks pretty complex so ruby provides a simpler way to do it. Ruby standard library has a singleton module that we can use. It defines the initialize method for me. It does lazy instantiation of the singleton object too.

==Conclusion==

 
==References==

CSC/ECE 517 Fall 2010/ch3 3f sm

2010-10-06T17:08:29Z

Smkakara:

Table of contents
Introduction
Singleton Pattern in Java
Singleton Pattern in Ruby
Conclusion
References